我正在为一个大型存储场进行设置，为了避免长达一个月的 fsck，我的计划是将存储分成多个较小的文件系统（这很好，因为我有一个存储良好的文件树，所以我可以轻松地在1/、2/、3/、4/等上安装单独的文件系统）。
我的困难在于，无法找到任何关于文件系统“合理”大小的列举，以使 fsck 时间同样“合理”。虽然我完全知道给定大小的绝对时间在很大程度上取决于硬件，但我似乎找不到任何关于不同文件系统大小的 ext3 fsck 时间曲线形状的描述，以及其他变量是什么（单个目录中充满文件的文件系统是否比树中数千个目录中每个目录有 10 个文件的文件系统花费的时间更长；大文件与小文件；满文件系统与空文件系统；等等）。
有人能提供关于这方面的经过充分研究的数据吗？除此之外，任何有关这些问题的轶事至少应该有助于指导我自己的实验，如果需要的话。
编辑: 澄清一下：无论文件系统是什么，如果元数据出现问题，就需要检查。是否启用或需要基于时间或挂载的重新文件系统检查并不是问题所在，我之所以特别要求有关 ext3 的数字，是因为这是最有可能被选择的文件系统。如果您知道某个文件系统的文件系统检查过程特别快，我愿意接受建议，但它确实需要是一个强大的选项（声称“文件系统 X 永远不需要文件系统检查！”将被嘲笑和嘲笑）。我也知道备份的必要性，而文件系统检查的愿望并不能代替备份，但是，当文件系统出现故障时，只是丢弃文件系统并从备份中恢复，而不是文件系统检查，似乎真的，真的愚蠢的权衡。
答案1
根据Mathur 等人的论文(第 29 页)，在某个时间点之后，e2fsck 时间会随着文件系统上的 inode 数量线性增长。如果该图有任何参考价值，则使用最多 1000 万个 inode 的文件系统会更有效。
切换到 ext4 会有所帮助 - 前提是你的文件系统没有加载到边缘，性能提升（由于不检查标记为未使用的 inode）没有明显的效果。
答案2
我认为你必须自己进行基准测试。在 Google 上快速搜索后没有发现任何结果，只是 ext4 fsck 比 ext3 快得多。
因此，创建一些 ext3 分区，100GB、200GB 等，直到达到您要使用的磁盘大小。然后用数据填充它们。如果您可以使用类似于生产数据的数据（每个目录的文件数、文件大小分布等），那么这将是最好的。请注意，只需从另一个分区或备份设备复制文件即可将它们完美地放置在磁盘上并进行碎片整理，因此您的测试将缺少大量写入/修改/删除带来的磁盘头寻道时间。
您还需要考虑并行 fsck。请参阅 /etc/fstab 中的最后几个字段。同一物理磁盘上的分区应按顺序进行；同一控制器上的多个磁盘可以并行进行，但请注意不要使控制器过载并降低其速度。
答案3
http://lmgtfy.com/?q=fsck+benchmark
看起来 ext4 文件系统上的 fsck 比 ext3 上的要快得多，有些报告称 ext4 fsck 比 ext3 快 10 倍甚至更多。
该搜索中的两篇非常有趣的文章是：
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/和http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
答案4
有什么原因导致您不能使用在重新启动时不会强制执行基于时间或挂载计数的 fsck 的文件系统？
（基于时间的 fsck 确实让我很烦 - 对于长时间正常运行的服务器，它几乎保证你在升级内核时必须执行完整的 fsck）。
无论如何，XFS 是不强制进行 fsck 的日志文件系统之一。值得一看。