设备映射器存储驱动程序(已弃用)
已弃用
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
模式使用“环回”机制,允许像读取和写入实际物理磁盘或块设备一样读取和写入本地磁盘上的文件。但是,环回机制的添加以及与OS文件系统层的交互意味着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
模式。此模式使用块设备来创建精简池。这比使用环回设备更快,更有效地使用系统资源,并且块设备可以根据需要增长。但是,它比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 自动扩展精简池的阈值(占总存储空间的百分比)。 | 否 | 80 | dm.thinp_autoextend_threshold=80 |
dm.thinp_autoextend_percent | 触发自动扩展时要增加精简池的百分比。 | 否 | 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 模式
以下过程创建一个配置为精简池的逻辑卷,用作存储池的后端。它假设您有一个空闲块设备位于/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
命令将卷转换为精简池和精简池元数据的存储位置。$ 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
配置文件配置精简池的自动扩展。$ 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
列中的输出报告(如上所示)卷为not monitored
,则需要显式启用监控。没有此步骤,无论应用配置文件中的任何设置如何,逻辑卷都不会自动扩展。$ sudo lvchange --monitor y docker/thinpool
再次运行
sudo lvs -o+seg_monitor
命令,仔细检查监控是否已启用。Monitor
列现在应报告逻辑卷正在monitored
。如果您之前在此主机上运行过 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
。编辑
/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 docker
服务:
$ 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
为空,池名称为docker-thinpool
。验证配置正确后,您可以删除包含先前配置的
/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
如果您遇到精简池的重复问题,您可以在/etc/docker/daemon.json
中将存储选项dm.min_free_space
设置为一个值(表示百分比)。例如,将其设置为10
可确保当可用空间达到或接近 10% 时,操作会发出警告并失败。请参阅引擎守护程序参考中的存储驱动程序选项。
增加正在运行设备的容量
您可以增加正在运行的精简池设备的容量。如果数据的逻辑卷已满且卷组已满,这将非常有用。具体步骤取决于您使用的是loop-lvm 精简池还是direct-lvm 精简池。
调整 loop-lvm 精简池的大小
调整loop-lvm
精简池大小最简单的方法是使用 device_tool 实用程序,但您也可以使用操作系统实用程序。
使用 device_tool 实用程序
名为device_tool.go
的社区贡献脚本可在moby/mobyGithub 仓库中获得。您可以使用此工具调整loop-lvm
精简池的大小,避免上述冗长过程。此工具不能保证有效,但您只应在非生产系统上使用loop-lvm
。
如果您不想使用device_tool
,您可以手动调整精简池大小。
要使用该工具,请克隆 Github 仓库,更改为
contrib/docker-device-tool
,然后按照README.md
中的说明编译该工具。使用该工具。以下示例将精简池大小调整为 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
请按照以下步骤增加精简池的大小。在此示例中,精简池为 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-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. 使用输出的第二个字段计算精简池的总扇区数。该数字以 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
在块级别运行,所以可写层中的多个块可以同时修改。可以使用标准的操作系统级备份实用程序备份快照。只需复制
/var/lib/docker/devicemapper/
即可。
Devicemapper工作流程
当您使用devicemapper
存储驱动程序启动Docker时,与镜像和容器层相关的所有对象都存储在/var/lib/docker/devicemapper/
中,它由一个或多个块级设备支持,这些设备可以是循环设备(仅限测试)或物理磁盘。
基础设备是最底层的对象。这是精简池本身。您可以使用
docker info
检查它。它包含一个文件系统。此基础设备是每个镜像和容器层的起点。基础设备是Device Mapper的实现细节,而不是Docker层。有关基础设备和每个镜像或容器层的信息存储在
/var/lib/docker/devicemapper/metadata/
中,格式为JSON。这些层是写时复制快照,这意味着它们在与父层不同之前都是空的。每个容器的可写层都挂载在
/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的数据根目录中,默认为/var/lib/docker
。如果您的容器生成大量日志消息,这可能会导致磁盘使用量增加或由于磁盘满而无法管理您的系统。您可以配置日志驱动程序以将容器日志存储在外部。