ext3 fsck时间与分区大小

我正在为大型存储服务器场进行设置，为了避免使用长达一个月的fscks，我的计划是将存储分为多个较小的文件系统（这很好，因为我有一个结构良好的文件树，所以可容易地具有单独的文件系统安装在1/，2/，3/，4/，等等）。

我的困难是找到文件系统的“合理”大小的任何枚举，以使fsck时间同样“合理”。尽管我完全知道给定大小的绝对时间将在很大程度上取决于硬件，但是对于文件系统大小不同的ext3 fsck时间，我似乎找不到任何关于曲线形状的描述，以及其他变量是什么（在一个树中成千上万个目录中，一个文件目录中包含文件的文件系统所花的时间要长于一个文件系统所花费的时间；一个大文件与小文件；完整文件系统与空文件系统等等）。

有人引用过对此进行深入研究的数字吗？否则，有关这些问题的轶事至少应有助于指导我自己的实验。

编辑：澄清：无论文件系统如何，如果元数据出问题，都需要检查。是否启用或需要基于时间或基于挂载的重新fscks并不成问题，而我要求提供专门针对ext3的编号的唯一原因是因为这是最有可能选择的文件系统。如果您知道文件系统具有特别快的fsck进程，我欢迎您提出建议，但是它确实是一个可靠的选择（声称“文件系统X永远不需要fscking！”会被嘲笑并嘲笑其长度） 。我也意识到需要备份，并且对fsck的渴望并不能替代备份，但是当它出现故障时，只是丢弃文件系统并从备份中恢复，而不是fscking似乎是真的，

根据Mathur等人的论文。（第29页），e2fsck时间在某个点之后随文件系统上inode的数量线性增长。如果需要解决这个问题，那么使用多达1000万个inode的文件系统会更有效。

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

我认为您将必须进行自己的基准测试。在google上进行的快速搜索没有发现任何内容，除了ext4 fscks比ext3快得多。

因此，创建一些ext3分区（100GB，200GB等），直到您要使用的磁盘大小。然后用数据填充它们。如果您可以使用与生产数据类似的数据（每个目录的文件，文件大小分布等），那将是最佳选择。请注意，简单地从另一个分区或备份设备复制文件会将它们完美地放置在磁盘上并进行碎片整理，因此您的测试将缺少很多磁盘头查找时间，而这些时间是由大量写入/修改/删除操作产生的。

您还需要考虑一下并行fscks。请参阅/ etc / fstab中的最后两个字段。同一物理磁盘上的分区应按顺序进行；可以并行完成同一控制器上的多个磁盘，但请注意不要使控制器过载并使它们减慢速度。

http://lmgtfy.com/?q=fsck+基准

看起来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/

有什么原因为什么您不能使用在重新启动时不会强制您使用时间或基于装载计数的fscks的文件系统？

（基于时间的fscks确实使我烦恼-对于长时间运行的服务器，它几乎可以保证每次升级内核时都必须执行完整的fsck）。

无论如何，XFS是不会强制使用fsck的日记文件系统之一。值得一看。