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。
对于支持它的系统，Linux 内核中包含了 devicemapper 支持。但是，要与 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 模式。
停止 Docker。
$ sudo systemctl stop docker编辑
/etc/docker/daemon.json。如果文件不存在，则创建它。假设文件为空，添加以下内容。{ "storage-driver": "devicemapper" }请参阅守护进程参考文档中每个存储驱动程序的所有存储选项
如果
daemon.json文件包含格式错误的 JSON，Docker 将无法启动。启动 Docker。
$ sudo systemctl start docker验证守护进程是否正在使用
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 模式。此模式使用块设备创建 thin pool。这比使用回环设备更快，更有效地利用系统资源，并且块设备可以根据需要增长。但是，它比 loop-lvm 模式需要更多的设置。
在满足先决条件后，按照以下步骤配置 Docker 以在 direct-lvm 模式下使用 devicemapper 存储驱动程序。
警告
更改存储驱动程序会使得您已创建的任何容器在本地系统上不可访问。使用
docker save保存容器，并将现有镜像推送到 Docker Hub 或私有仓库，这样您以后无需重新创建它们。
允许 Docker 配置 direct-lvm 模式
Docker 可以为您管理块设备，简化 direct-lvm 模式的配置。这仅适用于全新安装的 Docker。您只能使用单个块设备。如果您需要使用多个块设备，请改为手动配置 direct-lvm 模式。以下是可用的新配置选项
| 选项 | 描述 | 必需？ | 默认值 | 示例 |
|---|---|---|---|---|
dm.directlvm_device | 要为 direct-lvm 配置的块设备路径。 | 是 | dm.directlvm_device="/dev/xvdf" | |
dm.thinp_percent | 从传入的块设备中用于存储的空间百分比。 | 否 | 95 | dm.thinp_percent=95 |
dm.thinp_metapercent | 从传入的块设备中用于元数据存储的空间百分比。 | 否 | 1 | dm.thinp_metapercent=1 |
dm.thinp_autoextend_threshold | 当 lvm 自动扩展 thin pool 时所占总存储空间的百分比阈值。 | 否 | 80 | dm.thinp_autoextend_threshold=80 |
dm.thinp_autoextend_percent | 触发自动扩展时 thin pool 增加的百分比。 | 否 | 20 | dm.thinp_autoextend_percent=20 |
dm.directlvm_device_force | 即使块设备上已存在文件系统，是否也要格式化。如果设置为 false 且存在文件系统，则会记录错误并且文件系统保持不变。 | 否 | false | dm.directlvm_device_force=true |
编辑 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 模式
以下过程创建一个配置为 thin pool 的逻辑卷，用作存储池的后端。它假定您在 /dev/xvdf 处有一个备用块设备，并且有足够的可用空间来完成任务。设备标识符和卷大小在您的环境中可能不同，您应该在整个过程中替换为您自己的值。该过程还假定 Docker 守护进程处于 stopped 状态。
确定您要使用的块设备。该设备位于
/dev/下（例如/dev/xvdf），并且需要足够的可用空间来存储主机上运行的工作负载所需的镜像和容器层。固态硬盘是理想的选择。停止 Docker。
$ sudo systemctl stop docker安装以下软件包
RHEL / CentOS:
device-mapper-persistent-data,lvm2以及所有依赖项Ubuntu / Debian / SLES 15:
thin-provisioning-tools,lvm2以及所有依赖项
使用
pvcreate命令在步骤 1 中的块设备上创建物理卷。将/dev/xvdf替换为您的设备名称。警告
接下来的几个步骤是破坏性的，因此请确保您指定了正确的设备。
$ sudo pvcreate /dev/xvdf Physical volume "/dev/xvdf" successfully created.使用
vgcreate命令在同一设备上创建docker卷组。$ sudo vgcreate docker /dev/xvdf Volume group "docker" successfully created使用
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.使用
lvconvert命令将卷转换为 thin pool 以及 thin pool 的元数据存储位置。$ 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.通过
lvm配置文件配置 thin pool 的自动扩展。$ sudo vi /etc/lvm/profile/docker-thinpool.profile指定
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 }保存文件。
使用
lvchange命令应用 LVM 配置文件。$ sudo lvchange --metadataprofile docker-thinpool docker/thinpool Logical volume docker/thinpool changed.确保逻辑卷的监控已启用。
$ 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列的输出如上所示，报告该卷未被监控，则需要显式启用监控。没有这一步，无论应用配置文件中的任何设置如何，逻辑卷都不会自动扩展。$ sudo lvchange --monitor y docker/thinpool再次运行
sudo lvs -o+seg_monitor命令，仔细检查监控是否已启用。此时，Monitor列应报告逻辑卷正在被监控。如果您之前在此主机上运行过 Docker，或者
/var/lib/docker/存在，请将其移开，以便 Docker 可以使用新的 LVM pool 存储镜像和容器的内容。$ sudo su - # mkdir /var/lib/docker.bk # mv /var/lib/docker/* /var/lib/docker.bk # exit如果以下任何步骤失败且您需要恢复，可以移除
/var/lib/docker并将其替换为/var/lib/docker.bk。编辑
/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" ] }启动 Docker。
systemd:
$ sudo systemctl start dockerservice:
$ sudo service docker start使用
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将为空，并且 pool 名称为docker-thinpool。验证配置正确后，您可以移除包含旧配置的
/var/lib/docker.bk目录。$ sudo rm -rf /var/lib/docker.bk
管理 devicemapper
监控 thin pool
不要仅仅依赖 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% 时，操作会因警告而失败。请参阅Engine 守护进程参考中的存储驱动程序选项。
增加运行设备的容量
您可以增加运行中的 thin pool 设备的容量。当数据的逻辑卷已满且卷组已达到最大容量时，这很有用。具体过程取决于您使用的是 loop-lvm thin pool 还是 direct-lvm thin pool。
调整 loop-lvm thin pool 大小
调整 loop-lvm thin pool 大小的最简单方法是使用 device_tool 工具，但您也可以改用操作系统工具。
使用 device_tool 工具
社区贡献的名为 device_tool.go 的脚本可在 moby/moby Github 仓库中找到。您可以使用此工具调整 loop-lvm thin pool 的大小，避免上述冗长过程。此工具不保证有效，但您只应在非生产系统上使用 loop-lvm。
如果您不想使用 device_tool，可以手动调整 thin pool 大小。
要使用该工具，请克隆 Github 仓库，切换到
contrib/docker-device-tool目录，然后按照README.md中的说明编译该工具。使用该工具。以下示例将 thin pool 大小调整到 200GB。
$ ./device_tool resize 200GB
使用操作系统工具
如果您不想使用 device-tool 工具，可以使用以下过程手动调整 loop-lvm thin pool 大小。
在 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。
列出设备的大小。
$ 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使用
truncate命令将data文件的大小增加到 200 G，该命令用于增加或减少文件大小。请注意，减小文件大小是破坏性操作。$ sudo truncate -s 200G /var/lib/docker/devicemapper/data验证文件大小已更改。
$ 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回环文件已在磁盘上更改，但不在内存中。以 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重新加载 devicemapper 精简池。
a. 首先获取池名称。池名称是第一个字段，由
:分隔。此命令提取它。$ sudo dmsetup status | grep ' thin-pool ' | awk -F ': ' {'print $1'} docker-8:1-123141-poolb. 转储精简池的设备映射器表。
$ sudo dmsetup table docker-8:1-123141-pool 0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroingc. 使用输出的第二个字段计算精简池的总扇区数。该数字以 512k 扇区表示。一个 100G 文件有 209715200 个 512k 扇区。如果将此数字加倍到 200G，则会得到 419430400 个 512k 扇区。
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 精简池，请根据您的具体情况替换您的块设备和其他参数。
收集有关您的卷组的信息。
使用
pvdisplay命令查找当前由您的精简池使用的物理块设备以及卷组的名称。$ sudo pvdisplay |grep 'VG Name' PV Name /dev/xvdf VG Name docker在以下步骤中，请根据需要替换您的块设备或卷组名称。
扩展卷组，使用
vgextend命令并结合上一步中的VG Name，以及您的新块设备的名称。$ sudo vgextend docker /dev/xvdg Physical volume "/dev/xvdg" successfully created. Volume group "docker" successfully extended扩展
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.使用
docker info输出中的Data Space Available字段验证新的精简池大小。如果您扩展的是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 服务启动失败，请查找错误信息 "Non existing device"（设备不存在）。您需要使用此命令重新激活逻辑卷。
$ 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 会将镜像和层内容存储在精简池中，并通过将它们挂载在 /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在块级别运行，可写层中的多个块可以同时修改。快照可以使用标准的 OS 级别备份实用程序进行备份。只需复制
/var/lib/docker/devicemapper/即可。
Devicemapper 工作流程
当您使用 devicemapper 存储驱动程序启动 Docker 时，所有与镜像和容器层相关的对象都存储在 /var/lib/docker/devicemapper/ 中，该目录由一个或多个块级设备（回环设备（仅用于测试）或物理磁盘）支持。
基本设备是最低级别的对象。它就是精简池本身。您可以使用
docker info来检查它。它包含一个文件系统。这个基本设备是每个镜像和容器层的起点。基本设备是 Device Mapper 的实现细节，而不是 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 性能
按需分配的性能影响:devicemapper存储驱动程序使用按需分配操作从精简池中为容器的可写层分配新块。每个块为 64KB，这是用于写入的最小空间量。写入时复制的性能影响：容器第一次修改特定块时，该块会被写入容器的可写层。由于这些写入发生在块级别而不是文件级别，因此性能影响会最小化。然而，写入大量块仍然可能对性能产生负面影响，并且在这种情况下，
devicemapper存储驱动程序的性能实际上可能比其他存储驱动程序更差。对于写密集型工作负载，您应该使用数据卷，它们会完全绕过存储驱动程序。
性能最佳实践
使用 devicemapper 存储驱动程序时，请记住以下事项以最大化性能。
使用
direct-lvm：loop-lvm模式性能不佳，不应在生产环境中使用。使用快速存储：固态硬盘 (SSD) 提供比机械硬盘更快的读写速度。
内存使用情况：
devicemapper比其他一些存储驱动程序使用更多内存。每个启动的容器都会将其文件加载到内存中一份或多份副本，具体取决于同一文件的多少块同时被修改。由于内存压力，在高密度使用场景中，devicemapper存储驱动程序可能不是某些工作负载的正确选择。对写密集型工作负载使用卷：对于写密集型工作负载，卷提供最佳且最可预测的性能。这是因为它们绕过存储驱动程序，并且不会产生由精简配置和写入时复制引入的任何潜在开销。卷还有其他好处，例如允许您在容器之间共享数据，并且即使没有正在运行的容器使用它们，它们也会持久存在。
注意
当使用
devicemapper和json-file日志驱动程序时，容器生成的日志文件仍存储在 Docker 的 dataroot 目录中，默认为/var/lib/docker。如果您的容器生成大量日志消息，这可能导致磁盘使用量增加或由于磁盘满而无法管理您的系统。您可以配置一个日志驱动程序以将容器日志存储在外部。