我正在为一个大型存储场进行设置,为了避免需要长达一个月的fsck,我的计划是将存储分成许多较小的文件系统(这很好,因为我有一个很好的桶文件树,所以我可以很容易地在1/、2/、3/、4/等上安装单独的文件系统)。
我的困难在于找出文件系统的“合理”大小的枚举,以保持fsck时间类似于“合理”。虽然我完全知道,给定大小的绝对时间在很大程度上取决于硬件,但我似乎找不到任何关于不同文件系统大小的ext3 fsck时间曲线形状的描述,以及其他变量是什么(一个目录中充满文件的文件系统是否比树中数千个目录中每个目录中有10个文件的文件系统花费的时间更长;大文件与小文件;完整文件系统与空文件系统;等等)。
有人提到过关于这方面的任何经过充分研究的数字吗?如果做不到这一点,任何关于这些问题的轶事至少都应该有助于指导我自己的实验,如果需要的话。
编辑:为了澄清:不管文件系统是什么,如果元数据出了问题,就需要检查它。启用或需要基于时间或基于挂载的重fsck并不是问题所在,我要求提供有关ext3的数字的唯一原因是,这是最有可能被选择的文件系统。如果您知道一个文件系统具有特别快的fsck进程,我愿意听取建议,但它确实需要一个健壮的选项(声称“文件系统X从来不需要伪装!”)最后会被嘲笑和嘲笑)。我也意识到备份的必要性,而fsck的愿望并不是备份的替代品,然而,只是在文件系统出现故障时丢弃文件系统并从备份中恢复,而不是屏蔽备份,似乎是一种非常非常愚蠢的权衡。
发布于 2009-07-14 12:13:23
根据一个书名/作者: L. (第29页),在某个点之后,e2fsck时间与文件系统上的inode数量成线性增长。如果要查看图形,那么您可以更有效地处理多达1,000万inode的文件系统。
切换到ext4会有所帮助--在文件系统未加载到边框的情况下,性能增益(由于没有检查标记为未使用的inode)没有明显的效果。
发布于 2009-07-14 01:14:04
我想你得做你自己的基准。在谷歌上快速搜索没有发现任何东西,只是ext4比ext3快得多。
因此,创建一些ext3分区,100 be,200 be,等等,直到您将要使用的磁盘大小。然后用数据填充它们。如果您可以使用与生产数据类似的数据,(每个目录下的文件、文件大小分布等等)那就最好了。请注意,只需从另一个分区d备份设备中复制文件,就会将它们完美地放置在磁盘上,并将其碎片整理,因此您的测试将缺少大量写入/修改/删除的磁盘头查找时间。
你也需要考虑一些平行的fscks。请参阅/etc/fstab中的最后几个字段。同一物理磁盘上的分区应按顺序进行;同一控制器上的多个磁盘可以并行完成,但请注意不要使控制器过载并减慢它们的速度。
发布于 2009-07-14 01:15:47
http://lmgtfy.com/?q=fsck+benchmark
看起来,ext4文件系统上的fsck比ext3上的fsck要快得多,有些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/
https://serverfault.com/questions/40202
复制相似问题