我正在做一个大规模的存储农场的设置,为了避免需要长达一个月的时间,我的计划是将存储分割成许多较小的文件系统(这很好,因为我有一个分段文件树,所以我可以很容易地在1/
, 2/
, 3/
, 4/
等上安装单独的文件系统)。
我的困难在于find文件系统的“合理”大小的任何枚举,以保持fsck时间类似“合理”。 尽pipe我完全意识到给定大小的绝对时间在很大程度上取决于硬件,但我似乎无法find任何有关不同文件系统大小的ext3 fsck时间曲线形状的描述,以及其他variables(一个文件系统在一个目录中的文件占用时间要长于树中数千个目录中的每个文件中的10个文件;大文件vs小文件;完整文件系统vs空文件系统;等等)。
有没有人有任何关于这方面的研究数字的参考? 如果不这样做,那么有关这些问题的任何轶事至less应该有助于指导我自己的实验,如果这是必要的。
编辑 :澄清:无论文件系统,如果元数据出现问题,它将需要检查。 无论是基于时间还是基于挂载的重新启动都没有问题,我要求提供有关ext3的数字的唯一原因是因为这是最有可能select的文件系统。 如果你知道一个fsck过程特别快的文件系统,我愿意提供一些build议,但是它确实需要一个强大的选项(声称“文件系统X永远不需要fscking!”将会被嘲笑和嘲笑) 。 我也意识到需要备份,fsck的愿望不能替代备份,但是只是丢弃文件系统,并在备份恢复时,而不是备份,似乎是一个真正愚蠢的折衷。
根据Mathur等人的论文 (第29页),e2fsck时间随某个点后文件系统上的inode数量线性增长。 如果图表是任何事情的话,那么对于多达1000万个inode的文件系统来说,效率更高。
切换到ext4将有助于 – 在您的文件系统未被加载到边缘的情况下,性能增益(由于未检查inode标记为未使用)没有可察觉的效果。
我想你将不得不做你自己的基准。 谷歌的快速search没有透露任何东西,除了ext4 fscks比ext3快得多。
因此,创build一些ext3分区,100GB,200GB等,直到您将使用的磁盘大小。 然后用数据填充它们。 如果您可以使用类似于您的生产数据的数据(每个目录文件,文件大小分布等),那么这将是最好的。 请注意,简单地从另一个分区备份设备复制文件会将它们放置在完全布局和碎片整理的磁盘上,因此您的testing将缺less大量的写入/修改/删除操作所带来的大量磁盘头search时间。
你还需要考虑一下平行fscks。 查看/ etc / fstab中的最后几个字段。 在同一个物理磁盘上的分区应该按顺序进行; 同一个控制器上的多个磁盘可以并行工作,但请注意不要让控制器过载,并减慢速度。
http://lmgtfy.com/?q=fsck+benchmark
看起来像ext4文件系统上的fsck比ext3快得多,一些ext4 fsck的报告比ext3快10倍甚至更多。
这个search有两个非常有趣的文章是:
有没有什么原因,当你重新启动时,你不能使用不强制时间或基于mount数的fscks的文件系统?
(基于时间的fscks真的让我感到不安 – 对于一个长时间运行的服务器来说,它几乎可以保证当你升级内核的时候你必须做一个完整的fsck)。
无论如何,XFS是不强制fsck的日志文件系统之一。 值得一看。