我读过有关 ext4 校验和的文章（https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums)，但我不确定他们实际上校验的是什么。这个名字意味着只覆盖元数据，而不是文件中的实际数据？可以检测到哪些类型的错误？
答案1
我看不出对文件数据本身进行校验有什么好处。对于未知大小的数据块来说，这是一项昂贵的操作，并且重复了磁盘所做的工作。
此处的校验和提供文件系统级别的完整性检查，磁盘上的实际数据将依赖于磁盘内部校验和本身。通过校验元数据，您可以保护关键文件系统结构免受软件错误的侵害，并提供额外的防御层。
本质上，如果文件系统中的数据被损坏，校验和数据会告诉您可以忽略什么或者需要验证和重新检查什么，当磁盘本身已经完成校验和时，对大文件进行校验几乎没有好处（并且可能会产生很大的开销）。
实际文件校验也是最初写入数据的应用程序可以轻松完成的事情，存档格式会这样做，许多应用程序会检查数据完整性以确保它们没有加载垃圾。在文件系统级别以及应用程序和磁盘上执行此操作是多余的，而且几乎肯定是不必要的。
答案2
补丁作者总结了所涵盖的内容这里：
- 超级块存储其自身的crc32c。
- 每个inode存储crc32c(fs_uuid + inode_num + inode_gen + inode + slack_space_after_inode)
- 块和 inode 位图各自获得自己的 crc32c（fs_uuid + group_num + bitmap），存储在块组描述符中。
- 每个范围树块在块末尾未使用的空间中存储一个 crc32c(fs_uuid + inode_num + inode_gen + extend_entries)。
- 每个目录叶块都有一个看起来未使用的目录条目，其大小足够大以在块末尾存储 crc32c(fs_uuid + inode_num + inode_gen + block)。
- 每个目录 htree 块被缩短为在块末尾包含一个 crc32c(fs_uuid + inode_num + inode_gen + block)。
- 扩展属性块将 crc32c(fs_uuid + id + ea_block) 存储在标题中，其中 id 取决于引用计数，可以是 inode_num 和 inode_gen；也可以是块号。
- MMP 块将 crc32c(fs_uuid + mmpblock) 存储在 MMP 块的末尾。
- 块组现在可以使用 crc32c 而不是 crc16。
- 该日志现在具有 v2 校验和功能标志。
- crc32c（j_uuid + block）校验和已插入描述符块、提交块、撤销块和日志超级块。
- 描述符块中的每个块标签都有相关数据块的校验和。