我的 OpenBSD 服务器上有十几个文件系统，配有 12GB DDR3 和几个 1.5TB 硬盘。所有文件系统本身的大小一般都在 8GB 到 64GB 之间。
我注意到，即使遵循最佳实践（将它们保持得如此小），fsck重新启动时仍然非常慢。
是什么让fsck这么慢？原始文件系统大小？ inode 总数（used + ifree）？使用的索引节点数？完全是别的东西吗？有什么简单的方法可以fsck进一步改善时间吗？
答案1
运行 fsck 的目的是发现不一致之处。这样做意味着遍历文件系统来查看每个目录条目（目录/文件）及其背后的数据，以验证目录条目中的大小是否与数据的实际大小相匹配。这个过程一直很缓慢。在过去，我们没有注意到，因为文件系统要小得多，包含的文件数量也较少，并且计算机无论如何都要花费更长的时间来启动（服务是按顺序启动的）。由于旋转磁盘的速度并没有以与容量相同的方式增加，因此在系统启动期间运行文件系统检查变得越来越不可行。
这就是为什么许多相当现代的文件系统（如 ext3、ext4、reiserfs、XFS...）不再在重新启动时进行文件系统检查。相反，他们使用杂志用于簿记。在将更改写入磁盘之前，它会被写入日志。更改完成后，未完成的交易将在日志中标记为完成。如果系统在事务完成之前死亡，文件系统知道哪些事务正在进行，并且可以“重放”这些事务以使文件系统恢复到一致状态。这往往比运行文件系统检查要快得多。现代文件系统使用大量巧妙的技巧来减少维护日志的开销 - 实际上您通常不会注意到其中的差异。
最新一代的文件系统，如 btrfs、ZFS……使用写时复制技术，这意味着修改文件或元数据的事务永远不会覆盖现有数据。相反，新数据被写入单独的块。一旦新副本准备就绪，文件系统就会自动切换为使用新副本。这也有效地防止文件系统变得不一致（此外它还有一些其他优点）。
答案2
有什么简单的方法可以进一步改善 fsck 时间吗？
@HaukeLaging 是对的，可以通过更改文件系统上 inode 的密度来加快速度。看newfs -i。