github.com/hustcat/docker@v1.3.3-0.20160314103604-901c67a8eeab/docs/userguide/storagedriver/selectadriver.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Select a storage driver" 4 description = "Learn how select the proper storage driver for your container." 5 keywords = ["container, storage, driver, AUFS, btfs, devicemapper,zvfs"] 6 [menu.main] 7 parent = "engine_driver" 8 weight = -1 9 +++ 10 <![end-metadata]--> 11 12 # Select a storage driver 13 14 This page describes Docker's storage driver feature. It lists the storage 15 driver's that Docker supports and the basic commands associated with managing 16 them. Finally, this page provides guidance on choosing a storage driver. 17 18 The material on this page is intended for readers who already have an 19 [understanding of the storage driver technology](imagesandcontainers.md). 20 21 ## A pluggable storage driver architecture 22 23 Docker has a pluggable storage driver architecture. This gives you the 24 flexibility to "plug in" the storage driver that is best for your environment 25 and use-case. Each Docker storage driver is based on a Linux filesystem or 26 volume manager. Further, each storage driver is free to implement the 27 management of image layers and the container layer in its own unique way. This 28 means some storage drivers perform better than others in different 29 circumstances. 30 31 Once you decide which driver is best, you set this driver on the Docker daemon 32 at start time. As a result, the Docker daemon can only run one storage driver, 33 and all containers created by that daemon instance use the same storage driver. 34 The table below shows the supported storage driver technologies and their 35 driver names: 36 37 |Technology |Storage driver name | 38 |--------------|---------------------| 39 |OverlayFS |`overlay` | 40 |AUFS |`aufs` | 41 |Btrfs |`btrfs` | 42 |Device Mapper |`devicemapper` | 43 |VFS* |`vfs` | 44 |ZFS |`zfs` | 45 46 To find out which storage driver is set on the daemon , you use the 47 `docker info` command: 48 49 $ docker info 50 Containers: 0 51 Images: 0 52 Storage Driver: overlay 53 Backing Filesystem: extfs 54 Execution Driver: native-0.2 55 Logging Driver: json-file 56 Kernel Version: 3.19.0-15-generic 57 Operating System: Ubuntu 15.04 58 ... output truncated ... 59 60 The `info` subcommand reveals that the Docker daemon is using the `overlay` 61 storage driver with a `Backing Filesystem` value of `extfs`. The `extfs` value 62 means that the `overlay` storage driver is operating on top of an existing 63 (ext) filesystem. The backing filesystem refers to the filesystem that was used 64 to create the Docker host's local storage area under `/var/lib/docker`. 65 66 Which storage driver you use, in part, depends on the backing filesystem you 67 plan to use for your Docker host's local storage area. Some storage drivers can 68 operate on top of different backing filesystems. However, other storage 69 drivers require the backing filesystem to be the same as the storage driver. 70 For example, the `btrfs` storage driver on a Btrfs backing filesystem. The 71 following table lists each storage driver and whether it must match the host's 72 backing file system: 73 74 |Storage driver |Must match backing filesystem |Incompatible with | 75 |---------------|------------------------------|--------------------| 76 |`overlay` |No |`btrfs` `aufs` `zfs`| 77 |`aufs` |No |`btrfs` `aufs` | 78 |`btrfs` |Yes | N/A | 79 |`devicemapper` |No | N/A | 80 |`vfs` |No | N/A | 81 |`zfs` |Yes | N/A | 82 83 84 > **Note** 85 > Incompatible with means some storage drivers can not run over certain backing 86 > filesystem. 87 88 You can set the storage driver by passing the `--storage-driver=<name>` option 89 to the `docker daemon` command line, or by setting the option on the 90 `DOCKER_OPTS` line in the `/etc/default/docker` file. 91 92 The following command shows how to start the Docker daemon with the 93 `devicemapper` storage driver using the `docker daemon` command: 94 95 $ docker daemon --storage-driver=devicemapper & 96 97 $ docker info 98 Containers: 0 99 Images: 0 100 Storage Driver: devicemapper 101 Pool Name: docker-252:0-147544-pool 102 Pool Blocksize: 65.54 kB 103 Backing Filesystem: extfs 104 Data file: /dev/loop0 105 Metadata file: /dev/loop1 106 Data Space Used: 1.821 GB 107 Data Space Total: 107.4 GB 108 Data Space Available: 3.174 GB 109 Metadata Space Used: 1.479 MB 110 Metadata Space Total: 2.147 GB 111 Metadata Space Available: 2.146 GB 112 Udev Sync Supported: true 113 Deferred Removal Enabled: false 114 Data loop file: /var/lib/docker/devicemapper/devicemapper/data 115 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata 116 Library Version: 1.02.90 (2014-09-01) 117 Execution Driver: native-0.2 118 Logging Driver: json-file 119 Kernel Version: 3.19.0-15-generic 120 Operating System: Ubuntu 15.04 121 <output truncated> 122 123 Your choice of storage driver can affect the performance of your containerized 124 applications. So it's important to understand the different storage driver 125 options available and select the right one for your application. Later, in this 126 page you'll find some advice for choosing an appropriate driver. 127 128 ## Shared storage systems and the storage driver 129 130 Many enterprises consume storage from shared storage systems such as SAN and 131 NAS arrays. These often provide increased performance and availability, as well 132 as advanced features such as thin provisioning, deduplication and compression. 133 134 The Docker storage driver and data volumes can both operate on top of storage 135 provided by shared storage systems. This allows Docker to leverage the 136 increased performance and availability these systems provide. However, Docker 137 does not integrate with these underlying systems. 138 139 Remember that each Docker storage driver is based on a Linux filesystem or 140 volume manager. Be sure to follow existing best practices for operating your 141 storage driver (filesystem or volume manager) on top of your shared storage 142 system. For example, if using the ZFS storage driver on top of *XYZ* shared 143 storage system, be sure to follow best practices for operating ZFS filesystems 144 on top of XYZ shared storage system. 145 146 ## Which storage driver should you choose? 147 148 Several factors influence the selection of a storage driver. However, these two 149 facts must be kept in mind: 150 151 1. No single driver is well suited to every use-case 152 2. Storage drivers are improving and evolving all of the time 153 154 With these factors in mind, the following points, coupled with the table below, 155 should provide some guidance. 156 157 ### Stability 158 For the most stable and hassle-free Docker experience, you should consider the 159 following: 160 161 - **Use the default storage driver for your distribution**. When Docker 162 installs, it chooses a default storage driver based on the configuration of 163 your system. Stability is an important factor influencing which storage driver 164 is used by default. Straying from this default may increase your chances of 165 encountering bugs and nuances. 166 - **Follow the configuration specified on the CS Engine 167 [compatibility matrix](https://www.docker.com/compatibility-maintenance)**. The 168 CS Engine is the commercially supported version of the Docker Engine. It's 169 code-base is identical to the open source Engine, but it has a limited set of 170 supported configurations. These *supported configurations* use the most stable 171 and mature storage drivers. Straying from these configurations may also 172 increase your chances of encountering bugs and nuances. 173 174 ### Experience and expertise 175 176 Choose a storage driver that you and your team/organization have experience 177 with. For example, if you use RHEL or one of its downstream forks, you may 178 already have experience with LVM and Device Mapper. If so, you may wish to use 179 the `devicemapper` driver. 180 181 If you do not feel you have expertise with any of the storage drivers supported 182 by Docker, and you want an easy-to-use stable Docker experience, you should 183 consider using the default driver installed by your distribution's Docker 184 package. 185 186 ### Future-proofing 187 188 Many people consider OverlayFS as the future of the Docker storage driver. 189 However, it is less mature, and potentially less stable than some of the more 190 mature drivers such as `aufs` and `devicemapper`. For this reason, you should 191 use the OverlayFS driver with caution and expect to encounter more bugs and 192 nuances than if you were using a more mature driver. 193 194 The following diagram lists each storage driver and provides insight into some 195 of their pros and cons. When selecting which storage driver to use, consider 196 the guidance offered by the table below along with the points mentioned above. 197 198  199 200 201 ## Related information 202 203 * [Understand images, containers, and storage drivers](imagesandcontainers.md) 204 * [AUFS storage driver in practice](aufs-driver.md) 205 * [Btrfs storage driver in practice](btrfs-driver.md) 206 * [Device Mapper storage driver in practice](device-mapper-driver.md)