我们实验室的服务器曾如何处理 Docker 数据转移的问题?
修改配置文件
网上一般推荐的做法是这种: https://linuxiac.com/how-to-change-docker-data-directory/
修改 /etc/docker/daemon.json,向其中加入:
{ "data-root": "/new/docker/root" }
或者在 systemd 的服务启动程序中指定数据的路径。
不修改配置文件,只转移数据
但是我们实验室的服务器没有采用以上方案,却通过其他方式完成了从标准位置 /var/lib/docker 向其他位置的数据转移,而且两个文件夹中的数据是一样的。可以想到的方法有三种:软链接、硬链接、挂载。一个一个分析。
有个同学说我们服务器是从 /var/lib/docker 到 /data/docker 有软链接。但是用 sudo ls -dlh /var/lib/docker /data/docker
看两个目录都不是软链接。
是硬链接吗?/var/lib 的挂载点是 /,文件系统是 /dev/nvme0n1p3,/data 的挂载点是 /data,文件系统是 /dev/sda1。文件系统不一样,肯定不是硬链接。另外,如果真的是硬链接,不能将数据转移到另外一个分区,我们(准确地说是实验室前辈)原本的目标就是把数据从空间少的固态硬盘转移到空间多的机械硬盘,这和目标相悖。还可以继续验证:进目录里面去数子文件夹数量,加上 .
和结点本身需要的一个引用得到 13,docker 文件夹的链接数也刚好是 13,说明没有其他文件夹链接到这里。
再看 df
的结果,发现 /var/lib/docker 的挂载点是 /var/lib/docker,不是 /。用 findmnt
看一下:
findmnt -T /var/lib/docker
TARGET SOURCE FSTYPE OPTIONS
/var/lib/docker /dev/sda1[/docker] ext4 rw,relatime
可见服务器曾是用挂载的方式处理 docker 数据转移问题的。再看 /etc/fstab,果然有这么一条记录,而文件从 2 年以前就是这么写的了:
(base) xxx@yyy:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda3 during installation
UUID=c0ad5ae9-640d-478f-852c-85650bb068d4 / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=78c5af6f-b90c-4d1c-a309-d0a515c96147 /boot ext4 defaults 0 2
# swap was on /dev/sda2 during installation
#UUID=0c47825f-1e06-4e6c-84e3-b9445a4e57b1 none swap sw 0 0
UUID=7d7fe0a2-14df-4102-a91b-393fcf30063f /data ext4 defaults 0 0
/data/docker /var/lib/docker none bind 0 0
(base) xxx@yyy:~$ ls -lh /etc/fstab
-rw-rw-r-- 1 root root 875 6月 7 2022 /etc/fstab
这里的使用了 none 来作为 type,意义为绑定挂载(MS_BIND
)或者移动(MS_MOVE
),详细一点的解释可以参考 https://askubuntu.com/a/743812/1666727 。简单来说,none 是用来表示文件系统已经被 mount,现在只是为文件系统中的某个路径添加一个新的访问点。
根据 TLPI 第 18 章第 1 节:
使用绑定挂载(bind mount)可以获得与为目录创建硬链接相似的效果。