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