Device Mapper 存储驱动程序（已弃用）

已弃用

Device Mapper 驱动程序 已被弃用， 并且在 Docker Engine v25.0 中已被移除。如果您正在使用 Device Mapper， 您必须在升级到 Docker Engine v25.0 之前迁移到支持的存储驱动程序。请阅读 Docker 存储驱动程序 页面以获取支持的存储驱动程序。

Device Mapper 是一个基于内核的框架，支撑着 Linux 上许多高级卷管理技术。Docker 的 devicemapper 存储驱动利用该框架的精简配置和快照功能来进行镜像和容器管理。本文将 Device Mapper 存储驱动称为 devicemapper，并将内核框架称为 Device Mapper。

对于支持它的系统，devicemapper 支持已包含在 Linux 内核中。但是，需要特定配置才能在 Docker 中使用它。

devicemapper 驱动程序使用专用于 Docker 的块设备，并在块级别而非文件级别上运行。这些设备可以通过向 Docker 主机添加物理存储进行扩展，并且比在操作系统（OS）级别使用文件系统性能更好。

前提条件

• devicemapper 在运行于 CentOS、Fedora、 SLES 15、Ubuntu、Debian 或 RHEL 的 Docker Engine - Community 上受支持。
• devicemapper 需要 lvm2 和 device-mapper-persistent-data 软件包 被安装。
• 更改存储驱动程序会使您已创建的任何容器在本地系统上无法访问。使用 docker save 保存容器，并将现有镜像推送到 Docker Hub 或私有仓库，以便您无需稍后重新创建它们。

使用 devicemapper 存储驱动程序配置 Docker

在执行这些步骤之前，您必须首先满足所有 先决条件。

配置 loop-lvm 模式以进行测试

此配置仅适用于测试。loop-lvm 模式使用一种“回环”机制，允许从本地磁盘读取和写入文件，就像它们是实际的物理磁盘或块设备一样。 然而，回环机制的引入以及与操作系统文件系统层的交互，意味着IO操作可能会很慢且资源密集。 使用回环设备还可能引入竞态条件。 然而，设置 loop-lvm 模式有助于在尝试启用 direct-lvm 模式所需的更复杂设置之前，识别基本问题（如缺少用户空间包、内核驱动程序等）。因此，loop-lvm 模式应仅用于在配置 direct-lvm 之前进行基本测试。

对于生产系统，请参阅 为生产环境配置 direct-lvm 模式。

1. 停止 Docker。

   $ sudo systemctl stop docker
   

2. 编辑 /etc/docker/daemon.json。如果它尚不存在，请创建它。假设文件为空，添加以下内容。

   {
     "storage-driver": "devicemapper"
   }

   请参阅 守护进程参考文档 中每个存储驱动程序的所有存储选项

   如果 daemon.json 文件包含格式错误的 JSON，Docker 将无法启动。

3. 启动 Docker。

   $ sudo systemctl start docker
   

4. 验证守护进程是否正在使用 devicemapper 存储驱动。使用 docker info 命令并查找 Storage Driver。

   $ docker info
   
     Containers: 0
       Running: 0
       Paused: 0
       Stopped: 0
     Images: 0
     Server Version: 17.03.1-ce
     Storage Driver: devicemapper
     Pool Name: docker-202:1-8413957-pool
     Pool Blocksize: 65.54 kB
     Base Device Size: 10.74 GB
     Backing Filesystem: xfs
     Data file: /dev/loop0
     Metadata file: /dev/loop1
     Data Space Used: 11.8 MB
     Data Space Total: 107.4 GB
     Data Space Available: 7.44 GB
     Metadata Space Used: 581.6 KB
     Metadata Space Total: 2.147 GB
     Metadata Space Available: 2.147 GB
     Thin Pool Minimum Free Space: 10.74 GB
     Udev Sync Supported: true
     Deferred Removal Enabled: false
     Deferred Deletion Enabled: false
     Deferred Deleted Device Count: 0
     Data loop file: /var/lib/docker/devicemapper/data
     Metadata loop file: /var/lib/docker/devicemapper/metadata
     Library Version: 1.02.135-RHEL7 (2016-11-16)
   <...>
   

此主机运行在 loop-lvm 模式下，这在生产系统中不受支持。这表明 Data loop file 和一个 Metadata loop file 位于 /var/lib/docker/devicemapper 下的文件上。 这些是回环挂载的稀疏文件。对于生产系统，请参阅 为生产环境配置 direct-lvm 模式。

配置生产环境的 direct-lvm 模式

使用 devicemapper 存储驱动程序的生产主机必须使用 direct-lvm 模式。该模式使用块设备来创建精简池。这比 使用回环设备更快，更高效地利用系统资源，并且块设备 可以根据需要增长。然而，与 loop-lvm 模式相比，需要更多的设置。

在您满足 先决条件后，请按照以下步骤配置 Docker 以在 direct-lvm模式下使用 devicemapper存储驱动程序。

警告

更改存储驱动将使您已在本地系统上创建的任何容器无法访问。使用 docker save 来保存容器，并将现有镜像推送到 Docker Hub 或私有仓库，以便您无需稍后重新创建它们。

允许 Docker 配置 direct-lvm 模式

Docker 可以为您管理块设备，简化 direct-lvm 模式的配置。这仅适用于全新的 Docker 设置。 您只能使用一个块设备。如果您需要使用多个块设备， 请改为手动配置 direct-lvm 模式。 以下新的配置选项可用：

编辑 daemon.json 文件并设置适当的选项，然后重启 Docker 以使更改生效。以下 daemon.json 配置设置了上表中的所有选项。

{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.directlvm_device=/dev/xdf",
    "dm.thinp_percent=95",
    "dm.thinp_metapercent=1",
    "dm.thinp_autoextend_threshold=80",
    "dm.thinp_autoextend_percent=20",
    "dm.directlvm_device_force=false"
  ]
}

请参阅 守护进程参考文档 中每个存储驱动程序的所有存储选项

重启 Docker 以使更改生效。Docker 会为您调用命令来配置块设备。

警告

在 Docker 已为您准备块设备后更改这些值是不受支持的，并且会导致错误。

您仍然需要 执行定期维护任务。

手动配置 direct-lvm 模式

下面的过程创建一个配置为精简池的逻辑卷，用作存储池的后备。假设您在 /dev/xvdf 处有一个空闲的块设备，并且有足够的空闲空间来完成此任务。设备标识符和卷大小在您的环境中可能有所不同，您应该在整个过程中替换为您自己的值。该过程还假设 Docker 守护进程处于 stopped 状态。

1. 确定您要使用的块设备。该设备位于 /dev/（例如 /dev/xvdf）下，并且需要有足够的可用空间来存储 主机运行的工作负载的镜像和容器层。 固态硬盘是理想的选择。

2. 停止 Docker。

   $ sudo systemctl stop docker
   

3. 安装以下软件包：

   • RHEL / CentOS: device-mapper-persistent-data, lvm2, 以及所有 依赖项

   • Ubuntu / Debian / SLES 15: thin-provisioning-tools, lvm2, 及所有依赖项

4. 在步骤 1 中的块设备上创建物理卷，使用 pvcreate 命令。将您的设备名称替换为 /dev/xvdf。

   警告

   接下来的几个步骤具有破坏性，因此请确保您已指定正确的设备。

   $ sudo pvcreate /dev/xvdf
   
   Physical volume "/dev/xvdf" successfully created.
   

5. 在同一设备上创建一个 docker 卷组，使用 vgcreate 命令。

   $ sudo vgcreate docker /dev/xvdf
   
   Volume group "docker" successfully created
   

6. 使用 lvcreate 命令创建名为 thinpool 和 thinpoolmeta 的两个逻辑卷。最后一个参数指定在空间不足时允许自动扩展数据或元数据的可用空间量，作为临时应急措施。这些是推荐值。

   $ sudo lvcreate --wipesignatures y -n thinpool docker -l 95%VG
   
   Logical volume "thinpool" created.
   
   $ sudo lvcreate --wipesignatures y -n thinpoolmeta docker -l 1%VG
   
   Logical volume "thinpoolmeta" created.
   

7. 使用 lvconvert 命令将卷转换为精简池以及精简池的元数据存储位置。

   $ sudo lvconvert -y \
   --zero n \
   -c 512K \
   --thinpool docker/thinpool \
   --poolmetadata docker/thinpoolmeta
   
   WARNING: Converting logical volume docker/thinpool and docker/thinpoolmeta to
   thin pool's data and metadata volumes with metadata wiping.
   THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
   Converted docker/thinpool to thin pool.
   

8. 通过 lvm 配置文件配置精简池的自动扩展。

   $ sudo vi /etc/lvm/profile/docker-thinpool.profile
   

9. 指定 thin_pool_autoextend_threshold 和 thin_pool_autoextend_percent 值。

   thin_pool_autoextend_threshold 是在 lvm 尝试自动扩展可用空间之前已使用的空间百分比（100 = 禁用，不推荐）。

   thin_pool_autoextend_percent 是在自动扩展时添加到设备的空间量（0 = 禁用）。

   下面的示例在磁盘使用率达到 80% 时增加 20% 的容量。

   activation {
     thin_pool_autoextend_threshold=80
     thin_pool_autoextend_percent=20
   }

   保存文件。

10. 使用 lvchange 命令应用 LVM 配置文件。

    $ sudo lvchange --metadataprofile docker-thinpool docker/thinpool
    
    Logical volume docker/thinpool changed.
    

11. 确保逻辑卷的监控已启用。

    $ sudo lvs -o+seg_monitor
    
    LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor
    thinpool docker twi-a-t--- 95.00g             0.00   0.01                             not monitored
    

    如果 Monitor 列中的输出如上所示报告卷为 not monitored，则需要显式启用监控。如果不执行此步骤，无论应用配置文件中的任何设置如何，都不会发生逻辑卷的自动扩展。

    $ sudo lvchange --monitor y docker/thinpool
    

    通过第二次运行 sudo lvs -o+seg_monitor 命令，再次检查监控是否已启用。Monitor 列现在应该报告逻辑卷正在被 monitored。

12. 如果您之前在此主机上运行过 Docker，或者 /var/lib/docker/ 存在，请将其移开，以便 Docker 可以使用新的 LVM 池来 存储镜像和容器的内容。

    $ sudo su -
    # mkdir /var/lib/docker.bk
    # mv /var/lib/docker/* /var/lib/docker.bk
    # exit
    

    如果以下任何步骤失败并且您需要恢复，您可以移除 /var/lib/docker 并将其替换为 /var/lib/docker.bk。

13. 编辑 /etc/docker/daemon.json 并配置 devicemapper 存储驱动所需的选项。如果该文件之前为空，现在应包含以下内容：

    {
        "storage-driver": "devicemapper",
        "storage-opts": [
        "dm.thinpooldev=/dev/mapper/docker-thinpool",
        "dm.use_deferred_removal=true",
        "dm.use_deferred_deletion=true"
        ]
    }

14. 启动 Docker。

    systemd:

    $ sudo systemctl start docker
    

    服务:

    $ sudo service docker start
    

15. 使用 docker info 验证 Docker 是否正在使用新配置。

    $ docker info
    
    Containers: 0
     Running: 0
     Paused: 0
     Stopped: 0
    Images: 0
    Server Version: 17.03.1-ce
    Storage Driver: devicemapper
     Pool Name: docker-thinpool
     Pool Blocksize: 524.3 kB
     Base Device Size: 10.74 GB
     Backing Filesystem: xfs
     Data file:
     Metadata file:
     Data Space Used: 19.92 MB
     Data Space Total: 102 GB
     Data Space Available: 102 GB
     Metadata Space Used: 147.5 kB
     Metadata Space Total: 1.07 GB
     Metadata Space Available: 1.069 GB
     Thin Pool Minimum Free Space: 10.2 GB
     Udev Sync Supported: true
     Deferred Removal Enabled: true
     Deferred Deletion Enabled: true
     Deferred Deleted Device Count: 0
     Library Version: 1.02.135-RHEL7 (2016-11-16)
    <...>
    

    如果 Docker 配置正确，Data file 和 Metadata file 为空白，且池名称为 docker-thinpool。

16. 在您确认配置正确后，可以删除包含先前配置的 /var/lib/docker.bk 目录。

    $ sudo rm -rf /var/lib/docker.bk
    

管理 devicemapper

监控精简池

不要仅仅依赖 LVM 自动扩展。卷组会自动扩展，但卷仍可能被填满。您可以使用 lvs 或 lvs -a 监控卷上的可用空间。考虑在操作系统级别使用监控工具，例如 Nagios。

要查看 LVM 日志，您可以使用 journalctl：

$ sudo journalctl -fu dm-event.service

如果您在精简池（thin pool）中反复遇到问题，可以在 /etc/docker/daemon.json 中将存储选项 dm.min_free_space 设置为一个值（表示百分比）。例如，将其设置为 10 可以确保当可用空间达到或接近 10% 时，操作会因警告而失败。请参阅 引擎守护程序参考中的存储驱动程序选项。

增加运行中设备的容量

您可以在运行的 thin-pool 设备上增加池的容量。如果数据的逻辑卷已满且卷组已达到最大容量，这将非常有用。具体步骤取决于您使用的是 loop-lvm thin pool 还是 direct-lvm thin pool。

调整 loop-lvm 精简池大小

调整 loop-lvm 精简池大小的最简单方法是 使用 device_tool 工具， 但您也可以 使用操作系统工具 代替。

使用 device_tool 工具

一个名为 device_tool.go 的社区贡献脚本可在 moby/moby Github 仓库中找到。您可以使用此工具调整 loop-lvm 精简池的大小， 避免上述冗长的过程。此工具不保证一定有效，但您 应仅在非生产系统上使用 loop-lvm。

如果您不想使用 device_tool，可以 手动调整 thin pool 大小。

1. 要使用该工具，请克隆 Github 仓库，切换到 contrib/docker-device-tool 目录，并按照 README.md 中的说明 编译该工具。

2. 使用该工具。以下示例将精简池调整为 200GB。

   $ ./device_tool resize 200GB
   

使用操作系统实用程序

如果您不想 使用 device-tool 工具， 您可以使用以下过程手动调整 loop-lvm 精简池的大小。

在 loop-lvm 模式下，使用回环设备来存储数据，另一个用于存储元数据。loop-lvm 模式仅支持测试，因为它存在显著的性能和稳定性问题。

如果您正在使用 loop-lvm 模式，docker info 的输出将显示 Data loop file 和 Metadata loop file 的文件路径：

$ docker info |grep 'loop file'

 Data loop file: /var/lib/docker/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/metadata

按照以下步骤增加 thin pool 的大小。在此示例中， thin pool 为 100 GB，并增加到 200 GB。

1. 列出设备的大小。

   $ sudo ls -lh /var/lib/docker/devicemapper/
   
   total 1175492
   -rw------- 1 root root 100G Mar 30 05:22 data
   -rw------- 1 root root 2.0G Mar 31 11:17 metadata
   

2. 使用 truncate 命令将 data 文件的大小增加到 200 G， 该命令用于增加或减小文件的大小。请注意， 减小文件大小是一种破坏性操作。

   $ sudo truncate -s 200G /var/lib/docker/devicemapper/data
   

3. 验证文件大小已更改。

   $ sudo ls -lh /var/lib/docker/devicemapper/
   
   total 1.2G
   -rw------- 1 root root 200G Apr 14 08:47 data
   -rw------- 1 root root 2.0G Apr 19 13:27 metadata
   

4. 回环文件在磁盘上已更改，但在内存中未更改。列出内存中回环设备的大小，以GB为单位。重新加载它，然后再次列出大小。重新加载后，大小为200 GB。

   $ echo $[ $(sudo blockdev --getsize64 /dev/loop0) / 1024 / 1024 / 1024 ]
   
   100
   
   $ sudo losetup -c /dev/loop0
   
   $ echo $[ $(sudo blockdev --getsize64 /dev/loop0) / 1024 / 1024 / 1024 ]
   
   200
   

5. 重新加载 devicemapper 精简池。

   a. 首先获取池名称。池名称是第一个字段，以 :分隔。此命令提取它。

   $ sudo dmsetup status | grep ' thin-pool ' | awk -F ': ' {'print $1'}
   docker-8:1-123141-pool
   

   b. 转储精简池的设备映射表。

   $ sudo dmsetup table docker-8:1-123141-pool
   0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing
   

   c. 使用输出的第二个字段计算精简池的总扇区数。该数字以512-k扇区表示。一个100G的文件有209715200个512-k扇区。如果将此数字翻倍到200G，将得到419430400个512-k扇区。

   d. 使用以下三个 dmsetup 命令重新加载具有新扇区号的精简池。

   $ sudo dmsetup suspend docker-8:1-123141-pool
   $ sudo dmsetup reload docker-8:1-123141-pool --table '0 419430400 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing'
   $ sudo dmsetup resume docker-8:1-123141-pool
   

调整 direct-lvm 精简池大小

要扩展 direct-lvm 精简池，您需要先将新的块设备 附加到 Docker 主机，并记录内核分配给它的名称。在 本示例中，新的块设备是 /dev/xvdg。

按照以下步骤扩展 direct-lvm 精简池，根据您的实际情况替换块设备和其他参数。

1. 收集有关您的卷组的信息。

   使用 pvdisplay 命令查找当前由您的精简池使用的物理块设备和卷组的名称。

   $ sudo pvdisplay |grep 'VG Name'
   
   PV Name               /dev/xvdf
   VG Name               docker
   

   在以下步骤中，根据需要替换您的块设备或卷组名称。

2. 使用带有上一步中的 vgextend 命令以及您的新块设备名称来扩展卷组。

   $ sudo vgextend docker /dev/xvdg
   
   Physical volume "/dev/xvdg" successfully created.
   Volume group "docker" successfully extended
   

3. 扩展 docker/thinpool 逻辑卷。此命令立即使用 100% 的卷空间，不进行自动扩展。若要扩展元数据精简池，请使用 docker/thinpool_tmeta。

   $ sudo lvextend -l+100%FREE -n docker/thinpool
   
   Size of logical volume docker/thinpool_tdata changed from 95.00 GiB (24319 extents) to 198.00 GiB (50688 extents).
   Logical volume docker/thinpool_tdata successfully resized.
   

4. 使用 Data Space Available 字段在 docker info 的输出中验证新的精简池大小。如果您扩展了 docker/thinpool_tmeta 逻辑卷，请查找 Metadata Space Available。

   Storage Driver: devicemapper
    Pool Name: docker-thinpool
    Pool Blocksize: 524.3 kB
    Base Device Size: 10.74 GB
    Backing Filesystem: xfs
    Data file:
    Metadata file:
    Data Space Used: 212.3 MB
    Data Space Total: 212.6 GB
    Data Space Available: 212.4 GB
    Metadata Space Used: 286.7 kB
    Metadata Space Total: 1.07 GB
    Metadata Space Available: 1.069 GB
   <...>

重启后激活 devicemapper

如果您重启主机并发现 docker 服务启动失败， 请查找错误，“不存在的设备”。您需要使用以下命令重新激活 逻辑卷：

$ sudo lvchange -ay docker/thinpool

devicemapper 存储驱动的工作原理

警告

请勿直接操作 /var/lib/docker/中的任何文件或目录。这些文件和目录由Docker管理。

使用 lsblk 命令从操作系统 的角度查看设备及其存储池：

$ sudo lsblk

NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda                    202:0    0    8G  0 disk
└─xvda1                 202:1    0    8G  0 part /
xvdf                    202:80   0  100G  0 disk
├─docker-thinpool_tmeta 253:0    0 1020M  0 lvm
│ └─docker-thinpool     253:2    0   95G  0 lvm
└─docker-thinpool_tdata 253:1    0   95G  0 lvm
  └─docker-thinpool     253:2    0   95G  0 lvm

使用 mount 命令查看 Docker 正在使用的挂载点：

$ mount |grep devicemapper
/dev/xvda1 on /var/lib/docker/devicemapper type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

当您使用 devicemapper 时，Docker 会将镜像和层内容存储在 thinpool 中，并通过将其挂载到 /var/lib/docker/devicemapper/ 的子目录下，将其暴露给容器。

磁盘上的镜像和容器层

/var/lib/docker/devicemapper/metadata/ 目录包含有关 Devicemapper 配置本身以及存在的每个镜像和容器层的元数据。devicemapper 存储驱动程序使用快照，这些元数据包含有关这些快照的信息。这些文件采用 JSON 格式。

/var/lib/docker/devicemapper/mnt/ 目录包含每个现有 镜像和容器层的挂载点。镜像层挂载点是空的，但 容器的挂载点显示从容器内部看到的 容器文件系统。

镜像分层和共享

devicemapper 存储驱动器使用专用块设备而非格式化的文件系统，并在块级别操作文件，以在写时复制（CoW）操作期间实现最大性能。

快照

devicemapper 的另一个特性是它使用快照（有时也称为 精简设备 或 虚拟设备），这些快照将每一层引入的差异存储为非常小、轻量级的精简池。快照提供了许多好处：

• 容器之间共享的层在磁盘上只存储一次，除非它们是可写的。例如，如果您有 10 个不同的镜像，它们都基于 alpine，那么 alpine 镜像及其所有父镜像在磁盘上各自只存储一次。

• 快照是写时复制（CoW）策略的一种实现。这意味着只有在容器修改或删除某个文件或目录时，该文件或目录才会被复制到容器的可写层。

• 因为 devicemapper 在块级别上运行，所以可写层中的多个块可以同时被修改。

• 可以使用标准操作系统级别的备份工具来备份快照。只需复制 /var/lib/docker/devicemapper/。

Devicemapper 工作流程

当您使用 devicemapper 存储驱动启动 Docker 时，所有与镜像和容器层相关的对象都存储在 /var/lib/docker/devicemapper/ 中，后者由一个或多个块级设备支持，可以是回环设备（仅用于测试）或物理磁盘。

• 基础设备 是最低级别的对象。这就是精简池本身。 您可以使用 docker info 来检查它。它包含一个文件系统。这个基础 设备是每个镜像和容器层的起点。基础设备 是设备映射器的实现细节，而不是 Docker 层。

• 关于基础设备和每个镜像或容器层的元数据以JSON格式存储在 /var/lib/docker/devicemapper/metadata/中。这些层是 写时复制快照，这意味着它们在与父层不同之前是空的。

• 每个容器的可写层都挂载在 /var/lib/docker/devicemapper/mnt/ 中的一个挂载点上。对于每个 只读镜像层和每个已停止的容器，都存在一个空目录。

每个镜像层都是其下一层的快照。每个镜像的最底层是池中存在的基设备的快照。当您运行一个容器时，它是该容器所基于的镜像的快照。以下示例展示了一个具有两个运行中容器的 Docker 主机。第一个是 ubuntu 容器，第二个是 busybox 容器。

容器如何使用 devicemapper 进行读写操作

读取文件

使用 devicemapper，读取操作在块级别进行。下面的图表展示了在示例容器中读取单个块（0x44f）的高级流程。

应用程序在容器中对块 0x44f 发起读取请求。由于容器是镜像的精简快照，它不拥有该块，但它拥有指向最近的父镜像中该块的指针，并从那里读取该块。现在该块已存在于容器的内存中。

写入文件

写入新文件：使用 devicemapper 驱动程序，将新数据写入容器是通过按需分配 操作完成的。新文件的每个块都在容器的可写层中分配，并在该位置写入块。

更新现有文件：从该文件存在的最近层读取相关块。当容器写入该文件时，仅将修改后的块写入容器的可写层。

删除文件或目录: 当您在容器的可写层中删除文件或目录，或者当镜像层删除其父层中存在的文件时，devicemapper存储驱动程序会拦截对该文件或目录的进一步读取尝试，并响应表示该文件或目录不存在。

写入然后删除文件：如果容器写入文件并随后删除该文件，所有这些操作都发生在容器的可写层中。在这种情况下，如果您使用 direct-lvm，块将被释放。如果您使用 loop-lvm，块可能不会被释放。这是在生产环境中不使用 loop-lvm 的另一个原因。

Device Mapper 和 Docker 性能

• allocate-on demand 性能影响:

  devicemapper 存储驱动程序使用 allocate-on-demand 操作从 精简池中分配新块到容器的可写层。 每个块为 64KB，因此这是用于 写入的最小空间量。

• 写时复制性能影响：当容器首次修改特定块时，该块会被写入容器的可写层。由于这些写入发生在块级别而非文件级别，因此对性能的影响被最小化。然而，写入大量块仍可能对性能产生负面影响，且在此场景下，devicemapper存储驱动器的性能可能实际上比其他存储驱动器更差。对于写入密集型工作负载，您应该使用数据卷，这样可以完全绕过存储驱动器。

性能最佳实践

使用 devicemapper 存储驱动时，请牢记以下几点以最大化性能。

• 使用 direct-lvm: loop-lvm 模式性能较差，绝不应在生产环境中使用。

• 使用快速存储：固态硬盘（SSD）比机械硬盘提供更快的读写速度。

• 内存使用: devicemapper 比其他存储驱动程序使用更多的内存。每个启动的容器根据同一文件有多少块同时被修改，会将一个或多个文件副本加载到内存中。由于内存压力，devicemapper 存储驱动程序可能不是高密度使用场景中某些工作负载的正确选择。

• 对高写入工作负载使用卷：卷为高写入工作负载提供最佳且最可预测的性能。这是因为它们绕过存储驱动程序，并且不会引入精简配置和写时复制可能带来的任何潜在开销。卷还有其他优势，例如允许您在容器之间共享数据，并且在没有运行中的容器使用它们时仍然可以持久化。

  注意

  在使用 devicemapper 和 json-file 日志驱动程序时，容器生成的日志文件仍然存储在 Docker 的 dataroot 目录中，默认为 /var/lib/docker。如果您的容器生成大量日志消息，这可能会导致磁盘使用量增加或因磁盘已满而无法管理系统。您可以配置一个 日志驱动程序 来外部存储您的容器日志。

相关信息

• 卷
• 了解镜像、容器和存储驱动
• 选择存储驱动