☰

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

tag-icon • tag-icon filesystems ext4 ext3 ext2
检测 ext2、ext3 或 ext4 的可靠方法？

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

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

那么，该怎么做呢？

答案1

在查看了各种实用程序的代码和内核代码一段时间之后，似乎确实是什么@Hauke建议是 true -文件系统是否ext2纯粹由启用的选项定义。ext3ext4

来自维基百科页面在ext4：

向后兼容性

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

ext3 部分向前兼容 ext4。也就是说，ext4 可以作为 ext3 挂载（挂载时使用“ext3”作为文件系统类型）。但是，如果 ext4 分区使用扩展区（ext4 的一项主要新功能），则将失去作为 ext3 挂载的能力。

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

看完之后blkid用于区分不同的代码ext文件系统，我能够将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驱动程序并放弃其他驱动程序）。禁用功能仅意味着早期驱动程序不会出现文件系统问题，因此没有理由阻止它们挂载文件系统。

建议

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

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

如果你真的想全力以赴，那么查看日志校验和可能是确定没有这些标志的文件系统是否是（或者也许曾是）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/ext4功能可以很容易地在一个文件系统上启用，这ext2可能是文件系统类型确实是由功能定义的最好证明。

答案2

这不是一个直接的答案，但在查看每种类型的文件系统的输出时tune2fs -l ...显示出以下差异。

文件系统特性

外部2

文件系统功能： ext_attr resize_inode dir_index 文件类型稀疏_超级

EXT3

文件系统功能： has_journal ext_attr resize_inode dir_index 文件类型 need_recovery稀疏_超级

外部4

文件系统功能： has_journal ext_attr resize_inode dir_index 文件类型needs_recovery 范围flex_bg稀疏_超级大_文件巨大_文件uninit_bg dir_nlink extra_isize

日志参数

外部2

不显示日志记录参数。

EXT3

显示这个：

Journal inode:            8
外部4

显示这个：

Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1967934

相关内容