☰

哪些文件系统元数据操作实际记录在 ext4 和 xfs 中？

tag-icon • tag-icon linux filesystems ext4 xfs
哪些文件系统元数据操作实际记录在 ext4 和 xfs 中？

我找不到关于哪些文件系统元数据操作实际上保存到 ext4 和 xfs 文件系统日志的简单、直接的答案。请注意，我是不是询问 POSIX 声明什么是“原子的”。我更关心原子文件系统操作的子集是什么有效地fsync(2)耐用，因为在启用日志的情况下运行，无需始终向后弯腰。

我相当确定的操作：

  • creat(2)
  • link(2)
  • unlink(2)
  • rename(2)
  • mkdir(2)
  • rmdir(2)

我不完全确定的操作：

  • symlink(2)

这种symlink(2)情况是最令人不安的，因为似乎没有任何直接的方法 fsync(2)或fdatasync(2)存储符号链接内容的底层数据块。知道期刊会帮我处理这件事会让我松一口气。

答案1

我更关心原子文件系统操作的哪些子集通过启用日志运行而有效地持久，而不必一直向后弯曲和 fsync(2) 。

没有任何。如果您想确保崩溃后更改仍然存在，则必须进行 fsync。日志仅保证在发生崩溃时，您列出的任何操作都不会被执行一半完毕。

答案2

出于性能原因，ext4 默认情况下仅通过日志写入文件系统元数据。

我相信 XFS 还会记录所有元数据事务，除非您调整了文件系统。

答案3

您知道ext4 日志按块号操作而不是操作，对吗？ “元数据”可以是给定 inode 的实际数据块以外的任何内容，无论您使用什么操作来修改相关块。

答案4

xfs测试出现声称目录上的 fsync() 应该保留它包含的任何符号链接。

我还没有验证这一点。我可能错过了什么。

xfstests 被许多 Linux 文件系统开发人员使用。该测试位于“generic”目录中。这意味着它应该适用于所有 Linux 文件系统。 （或者至少，所有块设备文件系统。测试通过使用特殊的虚拟块设备进行）。

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).

相关内容