检测 ext2 或 ext3 或 ext4 的可靠方法？

Question

我需要使用文件系统超级块从 C/C++ 程序中检测文件系统类型。但是，我认为 ext2 和 ext4 的超级块之间没有太大区别。该s_rev_level场是相同的（= 1），则s_minor_rev_level是相同的（= 0）。

我可以从s_feature_compat（和其他功能字段）检查一些功能并尝试找到 ext2 不支持的功能。但是 - 格式化分区的人可能会故意禁用某些功能。因此，该方法可以检测到 ext4，但无法区分 ext2 和禁用了 ext4 特定功能的 ext4。

那么，该怎么做呢？

Answer 1

看着于各种用途的代码，并在一段时间的内核代码后，它似乎什么@Hauke建议是真实的-无论是文件系统ext2/ ext3/ext4纯粹是已启用的选项中定义。

从维基百科页面上ext4：

向后兼容

ext4 向后兼容 ext3 和 ext2，因此可以将 ext3 和 ext2 挂载为 ext4。这会稍微提高性能，因为 ext4 的某些新特性也可以与 ext3 和 ext2 一起使用，例如新的块分配算法。

ext3 部分向前兼容 ext4。也就是说，ext4 可以挂载为 ext3（挂载时使用“ext3”作为文件系统类型）。但是，如果 ext4 分区使用了扩展区（ext4 的一个主要新特性），那么挂载为 ext3 的能力就会丧失。

很可能已经知道，ext2和之间存在类似的兼容性ext3。

在查看用于区分不同文件系统的代码blkidext后，我能够将ext4文件系统转换为识别为ext3（并从那里到ext2）。您应该能够重复此操作：

truncate -s 100M testfs
mkfs.ext4 -O ^64bit,^extent,^flex_bg testfs <<<y
blkid testfs
tune2fs -O ^huge_file,^dir_nlink,^extra_isize,^mmp testfs
e2fsck testfs
tune2fs -O metadata_csum testfs
tune2fs -O ^metadata_csum testfs
blkid testfs
./e2fsprogs/misc/tune2fs -O ^has_journal testfs
blkid testfs

第一个blkid输出是：

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext4"

其次是：

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" SEC_TYPE="ext2" TYPE="ext3"

最后一个：

testfs: UUID="78f4475b-060a-445c-a5d2-0f45688cc954" TYPE="ext2"

请注意，我必须使用e2fsprogs发行版中可用的新版本来获取metadata_csum标志。设置，然后清除它的原因是因为我发现没有其他方法可以影响底层EXT4_FEATURE_RO_COMPAT_GDT_CSUM标志。metadata_csum( EXT4_FEATURE_RO_COMPAT_METADATA_CSUM) 和的基础标志EXT4_FEATURE_RO_COMPAT_GDT_CSUM是互斥的。设置metadata_csum禁用EXT4_FEATURE_RO_COMPAT_GDT_CSUM，但取消设置metadata_csum不会重新启用后者。

结论

缺乏对文件系统内部结构的深入了解，似乎是：

1. 日志校验和旨在成为创建的文件系统的定义功能，因为ext4您真的不应该禁用它，而且我已经管理的事实确实是e2fsprogs. 或者，

2. 所有ext4功能总是被设计为禁用，禁用它们确实使文件系统成为一个ext3文件系统。

无论哪种方式，文件系统之间的高度兼容性显然是一个设计目标，将此与 ReiserFS 和 Reiser4 进行比较，其中 Reiser4 是完全重新设计的。真正重要的是用于安装系统的驱动程序是否支持现有功能。正如维基百科文章所指出的，ext4驱动程序可以与ext3和一起使用ext2（实际上有一个内核选项可以始终使用ext4驱动程序并抛弃其他驱动程序）。禁用功能只是意味着较早的驱动程序在文件系统上没有问题，因此没有理由阻止它们挂载文件系统。

建议

区分extC 程序中的不同文件系统libblkid似乎是最好的选择。它是util-linux该mount命令用来尝试确定文件系统类型的一部分。API 文档在这里。

如果您必须自己执行检查，那么测试相同的标志libblkid似乎是正确的方法。尽管值得注意的是链接的文件没有提到EXT4_FEATURE_RO_COMPAT_METADATA_CSUM似乎在实践中经过测试的标志。

如果您真的想全力以赴，那么查看日志校验和可能是确定没有这些标志的文件系统 is (或者也许was )的可靠方法ext4。

更新

反其道而行之，将ext2文件系统提升为ext4：

truncate -s 100M test
mkfs.ext2 test
blkid test
tune2fs -O has_journal test
blkid test
tune2fs -O huge_file test
blkid test

三个blkid输出：

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" TYPE="ext2"

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext3"

test: UUID="59dce6f5-96ed-4307-9b39-6da2ff73cb04" SEC_TYPE="ext2" TYPE="ext4"

ext3/ ext4features 可以如此轻松地在开始的文件系统上启用的事实ext2可能是文件系统类型确实由功能定义的最佳证明。