ext3 fsck 时间与分区大小

wom*_*ble 9 ext3 fsck

我正在为大型存储场进行设置,为了避免需要长达一个月的 fscks,我的计划是将存储拆分为许多较小的文件系统(这很好,因为我有一个存储良好的文件树,所以可容易地具有单独的文件系统安装在1/2/3/4/,等等)。

我的困难在于找出文件系统的“合理”大小的任何枚举,以保持 fsck 时间同样“合理”。虽然我完全意识到给定大小的绝对时间在很大程度上取决于硬件,但我似乎无法找到任何关于文件系统大小不同的 ext3 fsck 时间曲线形状的描述,以及其他变量是什么(在单个目录中充满文件的文件系统是否比在树中数千个目录中的每个目录中包含 10 个文件的文件系统花费的时间更长;大文件与小文件;完整文件系统与空文件系统;等等)。

有没有人参考过任何经过充分研究的数字?如果做不到这一点,关于这些问题的任何轶事至少应该有助于指导我自己的实验,如果需要的话。

编辑:澄清:无论文件系统如何,如果元数据出现问题,都需要进行检查。是否启用或需要基于时间或挂载的 re-fscks 不是问题,我要求特别关于 ext3 的数字的唯一原因是因为这是最有可能选择的文件系统。如果你知道一个文件系统有一个特别快的 fsck 进程,我愿意接受建议,但它确实需要是一个强大的选择(声称“文件系统 X 从不需要 fscking!”将被嘲笑和嘲笑) . 我也意识到需要备份,并且 fsck 的愿望不能替代备份,但是只是丢弃文件系统并在出现故障时从备份中恢复,而不是 fscking 它,似乎真的,

tow*_*owo 6

根据Mathur 等人一篇论文。(第 29 页),e2fsck 时间在某个点之后随着文件系统上的 inode 数量线性增长。如果该图有任何意义,那么使用多达 1000 万个 inode 的文件系统会更有效。

切换到 ext4 会有所帮助 - 在您的文件系统未加载到边缘的情况下,性能提升(由于不检查标记为未使用的 inode)没有明显影响。