fsck 对 30 TB 的卷需要多长时间？

Question

11 月中旬，我从一家托管公司租用的 VPS 停止响应。当我联系支持人员时，他们解释说数据中心断电导致强制重启和 fsck。最后，我问为什么花了这么长时间，他们告诉我卷的大小是 30 TB。我上次收到更新是在二月份，他们还没有回复我最近的询问。

我知道 fsck 对于某些文件系统来说可能会非常慢，但是 fsck 是否可能在 30 TB 的卷上花费 6 个月的时间，或者我应该假设这家托管公司在骗我，以便我继续每月支付账单？

Answer 1

fsck速度主要取决于文件数量以及它们在相应目录中的分布情况。话虽如此，6 个月的时间fsck绝对是荒谬的：它最多应该在几个小时内完成，特别是如果使用xfs具有快速xfs_repair实用程序的程序。这里您会发现一些fsck规模庞大的跑步活动 - 全部在一小时内完成（3600 秒）。因此，您的跑步活动不可能fsck仍在进行中。

无论如何，意外断电将不是造成全面打击fsck，而不是非常快（几秒钟）期刊重播. 然而，如果一些关键文件被损坏，操作系统将无法启动。

但他们可能只是骗了你。你应该立即停止付款，要求解释并申请全额退款。

Answer 2

推测：他们的系统使用无 BBU/FBWC 的 RAID（甚至是软件 RAID），并将所有可能的写入缓存（包括硬盘本身的缓存）设置为最激进的设置，以便以最低的成本获得最大的性能。在这样的设置下发生硬断电可能会导致日志文件系统处于日志不可信且无法用于恢复的状态。问题是，这样的系统会积极地重新排序和推迟写入，这意味着写入日志条目可能会导致数据操作丢失……或者日志条目在重要的数据操作上丢失。

从最坏情况下的中断中恢复这样的系统可能意味着您必须执行“缓慢”的 fsck/修复，实际检查所有文件系统结构，对于 30TB 的数据，这确实可能需要一两天的时间……并且您很可能必须运行多个修复周期。此外，人员可能并不总是可以监控这一点，您很容易每周只进行一次 fsck。他们可能放弃并忘记了。

Answer 3

对于大多数文件系统来说，即使出现错误，速度也会更快，因为通常只检查元数据。

在最坏的情况下，它可能会读取整个磁盘，（例如类似fsck.ext4 -cc /dev/sda，对每个块进行非破坏性写入测试），对于 30 TB 的数据，可能需要几天的时间。如果你知道驱动器的速度，你可以计算尺寸/速度对于消费级硬盘，大约100MB/秒复制几 TB 的数据所花的时间可能比大多数人预期的要多。

如果这是您的服务器，您可能会遇到这样的问题：启动后当fsck系统询问您是否要修复错误时，服务器会挂起。但数据中心管理员不会fsck在所有 VPS 都离线的情况下让服务器挂起 6 个月。

所以他们要么在骗你，要么就是有很大的误解。或者他们之前正在运行 fsck，但运行结束后没有向你通报新问题。