github.com/vieux/docker@v0.6.3-0.20161004191708-e097c2a938c7/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` or `overlay2`|
    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  
    51      Containers: 0
    52      Images: 0
    53      Storage Driver: overlay
    54       Backing Filesystem: extfs
    55      Execution Driver: native-0.2
    56      Logging Driver: json-file
    57      Kernel Version: 3.19.0-15-generic
    58      Operating System: Ubuntu 15.04
    59      ... output truncated ...
    60  
    61  The `info` subcommand reveals that the Docker daemon is using the `overlay`
    62  storage driver with a `Backing Filesystem` value of `extfs`. The `extfs` value
    63  means that the `overlay` storage driver is operating on top of an existing
    64  (ext) filesystem. The backing filesystem refers to the filesystem that was used
    65   to create the Docker host's local storage area under `/var/lib/docker`.
    66  
    67  Which storage driver you use, in part, depends on the backing filesystem you
    68  plan to use for your Docker host's local storage area. Some storage drivers can
    69   operate on top of different backing filesystems. However, other storage
    70  drivers require the backing filesystem to be the same as the storage driver.
    71  For example, the `btrfs` storage driver on a Btrfs backing filesystem. The
    72  following table lists each storage driver and whether it must match the host's
    73  backing file system:
    74  
    75  |Storage driver |Commonly used on |Disabled on                                         |
    76  |---------------|-----------------|----------------------------------------------------|
    77  |`overlay`      |`ext4` `xfs`     |`btrfs` `aufs` `overlay` `overlay2` `zfs` `eCryptfs`|
    78  |`overlay2`     |`ext4` `xfs`     |`btrfs` `aufs` `overlay` `overlay2` `zfs` `eCryptfs`|
    79  |`aufs`         |`ext4` `xfs`     |`btrfs` `aufs` `eCryptfs`                           |
    80  |`btrfs`        |`btrfs` _only_   |   N/A                                              |
    81  |`devicemapper` |`direct-lvm`     |   N/A                                              |
    82  |`vfs`          |debugging only   |   N/A                                              |
    83  |`zfs`          |`zfs` _only_     |   N/A                                              |
    84  
    85  
    86  > **Note**
    87  > "Disabled on" means some storage drivers can not run over certain backing
    88  > filesystem.
    89  
    90  You can set the storage driver by passing the `--storage-driver=<name>` option
    91  to the `dockerd` command line, or by setting the option on the
    92  `DOCKER_OPTS` line in the `/etc/default/docker` file.
    93  
    94  The following command shows how to start the Docker daemon with the
    95  `devicemapper` storage driver using the `dockerd` command:
    96  
    97      $ dockerd --storage-driver=devicemapper &
    98  
    99      $ docker info
   100  
   101      Containers: 0
   102      Images: 0
   103      Storage Driver: devicemapper
   104       Pool Name: docker-252:0-147544-pool
   105       Pool Blocksize: 65.54 kB
   106       Backing Filesystem: extfs
   107       Data file: /dev/loop0
   108       Metadata file: /dev/loop1
   109       Data Space Used: 1.821 GB
   110       Data Space Total: 107.4 GB
   111       Data Space Available: 3.174 GB
   112       Metadata Space Used: 1.479 MB
   113       Metadata Space Total: 2.147 GB
   114       Metadata Space Available: 2.146 GB
   115       Thin Pool Minimum Free Space: 10.74 GB
   116       Udev Sync Supported: true
   117       Deferred Removal Enabled: false
   118       Data loop file: /var/lib/docker/devicemapper/devicemapper/data
   119       Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
   120       Library Version: 1.02.90 (2014-09-01)
   121      Execution Driver: native-0.2
   122      Logging Driver: json-file
   123      Kernel Version: 3.19.0-15-generic
   124      Operating System: Ubuntu 15.04
   125      <output truncated>
   126  
   127  Your choice of storage driver can affect the performance of your containerized
   128  applications. So it's important to understand the different storage driver
   129  options available and select the right one for your application. Later, in this
   130   page you'll find some advice for choosing an appropriate driver.
   131  
   132  ## Shared storage systems and the storage driver
   133  
   134  Many enterprises consume storage from shared storage systems such as SAN and
   135  NAS arrays. These often provide increased performance and availability, as well
   136   as advanced features such as thin provisioning, deduplication and compression.
   137  
   138  The Docker storage driver and data volumes can both operate on top of storage
   139  provided by shared storage systems. This allows Docker to leverage the
   140  increased performance and availability these systems provide. However, Docker
   141  does not integrate with these underlying systems.
   142  
   143  Remember that each Docker storage driver is based on a Linux filesystem or
   144  volume manager. Be sure to follow existing best practices for operating your
   145  storage driver (filesystem or volume manager) on top of your shared storage
   146  system. For example, if using the ZFS storage driver on top of *XYZ* shared
   147  storage system, be sure to follow best practices for operating ZFS filesystems
   148  on top of XYZ shared storage system.
   149  
   150  ## Which storage driver should you choose?
   151  
   152  Several factors influence the selection of a storage driver. However, these two
   153   facts must be kept in mind:
   154  
   155  1. No single driver is well suited to every use-case
   156  2. Storage drivers are improving and evolving all of the time
   157  
   158  With these factors in mind, the following points, coupled with the table below,
   159   should provide some guidance.
   160  
   161  ### Stability
   162  For the most stable and hassle-free Docker experience, you should consider the
   163  following:
   164  
   165  - **Use the default storage driver for your distribution**. When Docker
   166  installs, it chooses a default storage driver based on the configuration of
   167  your system. Stability is an important factor influencing which storage driver
   168  is used by default. Straying from this default may increase your chances of
   169  encountering bugs and nuances.
   170  - **Follow the configuration specified on the CS Engine
   171  [compatibility matrix](https://www.docker.com/compatibility-maintenance)**. The
   172   CS Engine is the commercially supported version of the Docker Engine. It's
   173  code-base is identical to the open source Engine, but it has a limited set of
   174  supported configurations. These *supported configurations* use the most stable
   175  and mature storage drivers. Straying from these configurations may also
   176  increase your chances of encountering bugs and nuances.
   177  
   178  ### Experience and expertise
   179  
   180  Choose a storage driver that you and your team/organization have experience
   181  with. For example, if you use RHEL or one of its downstream forks, you may
   182  already have experience with LVM and Device Mapper. If so, you may wish to use
   183  the `devicemapper` driver.
   184  
   185  If you do not feel you have expertise with any of the storage drivers supported
   186   by Docker, and you want an easy-to-use stable Docker experience, you should
   187  consider using the default driver installed by your distribution's Docker
   188  package.
   189  
   190  ### Future-proofing
   191  
   192  Many people consider OverlayFS as the future of the Docker storage driver.
   193  However, it is less mature, and potentially less stable than some of the more
   194  mature drivers such as `aufs` and `devicemapper`.  For this reason, you should
   195  use the OverlayFS driver with caution and expect to encounter more bugs and
   196  nuances than if you were using a more mature driver.
   197  
   198  The following diagram lists each storage driver and provides insight into some
   199  of their pros and cons. When selecting which storage driver to use, consider
   200  the guidance offered by the table below along with the points mentioned above.
   201  
   202  ![](images/driver-pros-cons.png)
   203  
   204  ### Overlay vs Overlay2
   205  
   206  OverlayFS has 2 storage drivers which both make use of the same OverlayFS
   207  technology but with different implementations and incompatible on disk
   208  storage. Since the storage is incompatible, switching between the two
   209  will require re-creating all image content. The `overlay` driver is the
   210  original implementation and the only option in Docker 1.11 and before.
   211  The `overlay` driver has known limitations with inode exhaustion and
   212  commit performance. The `overlay2` driver addresses this limitation, but
   213  is only compatible with Linux kernel 4.0 and later. For users on a pre-4.0
   214  kernel or with an existing `overlay` graph, it is recommended to stay
   215  on `overlay`. For users with at least a 4.0 kernel and no existing or required
   216  `overlay` graph data, then `overlay2` may be used.
   217  
   218  > **Note**
   219  > `overlay2` graph data will not interfere with `overlay` graph data. However
   220  > when switching to `overlay2`, the user is responsible for removing
   221  > `overlay` graph data to avoid storage duplication.
   222  
   223  ## Related information
   224  
   225  * [Understand images, containers, and storage drivers](imagesandcontainers.md)
   226  * [AUFS storage driver in practice](aufs-driver.md)
   227  * [Btrfs storage driver in practice](btrfs-driver.md)
   228  * [Device Mapper storage driver in practice](device-mapper-driver.md)