☰

为什么使用 mkfs 创建的文件系统不能立即使用

tag-icon • tag-icon linux filesystems
为什么使用 mkfs 创建的文件系统不能立即使用

为什么创建的文件系统mkfs在创建后不能立即可用？

以下命令行可能最能描述我所看到的内容：

/sbin/mkfs.ext4 /dev/sdc && lsblk -o uuid --noheadings /dev/sdc

首先，我创建一个 ext4 文件系统/dev/sdc，然后尝试立即显示该文件系统的 UUID。

这是这些命令的相应输出：

mke2fs 1.44.1 (24-Mar-2018)
/dev/sdc contains a ext4 file system
        created on Wed Oct  5 00:40:08 2022
Proceed anyway? (y,N) y
Discarding device blocks: done
Creating filesystem with 268435456 4k blocks and 67108864 inodes
Filesystem UUID: d54169aa-faab-49b5-b0fd-fdf98b603df0
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

434269b5-59e4-4fd0-95f0-376090e0e0a9

您会注意到输出中的“文件系统 UUID”与输出末尾显示mkfs.ext4的输出不匹配。lsblk

然而，如果我lsblk -o uuid --noheadings /dev/sdc稍后再运行，我会得到：

d54169aa-faab-49b5-b0fd-fdf98b603df0

这与输出一致mkfs.ext4。为什么延迟？

答案1

如果 mkfs.ext4 没有返回错误，则可以使用它，包括文件系统 UUID。mount UUID=434269b5-59e4-4fd0-95f0-376090e0e0a9 /mnt 或者其他什么，如果您满意的话，请将其放入 fstab 中。

在 Linux 上，一些发行版认为良好的硬件体验意味着一些用户空间程序会干预该过程。即 udev（硬件事件系统）和 blkid（块设备探测功能）。根据 man lsblk：

注意，lsblk 可能会在 udev 尚未获得最近添加或修改的设备的所有信息时及时执行。在这种情况下，建议在 lsblk 之前使用 udevadm set 与 udev 同步。

用户空间程序创建了一个文件系统，用户空间程序计算出了生成的 UUID，但它们之间没有直接集成。此外，lsblk 有一个缓存。这会导致短暂的延迟。以及来自任何以前文件系统的陈旧数据，请注意，您是在现有的 ext4 上重新创建，而没有使用 wipefs 命令之类的命令。

blkid --uuid d54169aa-faab-49b5-b0fd-fdf98b603df0 直接挂载它会导致低级别的 blkid 探测，与默认扫描所有块设备以查找未知卷的命令相同。

相关内容