在将 EBS 卷附加到正在运行的 Linux(在本例中为 NixOS)实例时,我们遇到了一个奇怪的问题(为了在该附加卷上增加文件系统;它是我们关闭的另一台机器的 NixOS 根文件系统下)。
在 attach 之前,一切正常:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 100G 0 disk
└─xvda1 202:1 0 100G 0 part
附加后,lsblk
奇怪地声称附加卷的分区包含/
当前机器的已安装分区:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 100G 0 disk
└─xvda1 202:1 0 100G 0 part /nix/store
xvdf 202:80 0 400G 0 disk
└─xvdf1 202:81 0 200G 0 part /
这根本没有意义:
只需“插入”该磁盘,Linux 就会认为根文件系统挂载只是“翻转”到了新磁盘。(这/nix/store
是一个 NixOS 只读绑定挂载)以某种方式保留在正确的磁盘上。
Linux中dmesg
/之外没有任何消息指出磁盘已附加:journalctl
Apr 28 11:57:21 mymachine kernel: blkfront: xvdf: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
Apr 28 11:57:21 mymachine kernel: xvdf: xvdf1
在fdisk -l
中,两个磁盘看起来很正常,并且有不同Disk identifier
的 s。
这是不可能的umount /dev/xvdf1
;它说坐骑很忙。
为了增加分区的目标,growpart /dev/xvdf 1
无论如何都可以工作,但resize2fs /dev/xvdf1
失败了:
Filesystem at /dev/xvdg1 is mounted on /; on-line resizing required
old_desc_blocks = 25, new_desc_blocks = 50
resize2fs: No space left on device While checking for on-line resizing support
这是怎么回事,为什么Linux会混淆这些磁盘?
原因是
by-label
坐骑。出于声明性自动化的原因(我们有很多机器),我们机器的每个根文件系统都有相同的 ext4 文件系统标签
nixos
:将其中两个附加到同一台机器上会使 Linux 感到困惑。
所以解决方案是:
by-label
使用相同标签安装的 AWS 机器来执行文件系统增长。