为什么 fsck 在 ext4 文件系统上如此缓慢？我一直使用 reiserfs 或 xfs，在这些系统上 fsck 非常快，只需几秒钟。现在我决定尝试 ext4，但令我失望的是，每次系统必须 fsck 我的 homedir 时都要花很长时间（在我的 250GB 主分区上可能需要 25 分钟，该分区已满 85%）。也许是因为它是从 ext3 转换而来的？
答案1
使用附加选项“ -O extent,uninit_bg”重新创建文件系统将改善您的 ext4 fsck 时间。
- “extent” 将减少大文件的元数据开销
- “uninit_bg” 将创建一个 fs，但不初始化所有块组。这将改善 mkfs 和 fsck，因为需要检查的元数据更少（至少只要您的 fs 未满）。
答案2
从 ext3 转换不会充分利用扩展区。它只是升级 inode 并将它们保留为大小为 1 的扩展区。如果您通过 tar 之类的程序运行文件，您可能能够获取更好的压缩扩展区文件。
如何从 ext3 转换为 ext4 也很重要；不同的选项具有不同的功能，可能会影响 fsck 时间。此外，我认为对一个完整的驱动器进行 fsck 需要更长的时间；毕竟你要检查大约 200GB 的数据，并且 inode 占用的大小可能是原来的三倍。
您可能要做的是向构建您正在使用的内核的发行版或直接向内核 bugzilla 提交错误报告。毕竟，这是上游有兴趣诊断和修复的行为。
答案3
我的 400GB ext3 分区在 fsck 期间也需要很长时间。此外，随着卷越来越大，fsck 会花费太长时间。引用本文：
1 EB（艾字节）在很长一段时间内都足以存储——事实上，在这种大小的文件系统上完整运行 e2fsck（在当前硬件上）需要 100 多年。
所以，我真的希望文件系统及其工具能够很快得到改进，否则在它们上运行 fsck 将是不可行的。
答案4
我跑了fsck -V -y 两次在我的 2TB RAID1 ext4 USB 安装的 LaCie 磁盘上。在每种情况下，该过程都运行了 24 小时，进度可见但未完成。在每种情况下，我都终止了该过程并运行，fsck -V -C -y几分钟后就完成了。参数-C只是应该提供一个进度条，但它似乎也消除了一些巨大的时间浪费。