我们正在运营一个网站，目前该网站的页面浏览量为 300-500 万次。我们的网站是一个文件共享网站，因此它包含 250,000 个文件和几千个符号链接。
硬盘为1500GB SATA盘。
使用hdparm我们发现我们的硬盘速度已经降低到15-20MB/s，80兆/秒。
所以现在我们要运行fsck来修复磁盘问题。
- 会
fsck解决这个问题吗？ - 需要多长时间才能
fsck完成（我们只是想计算我们将要经历的停机时间）？
答案1
随着同时访问的文件数量增加，速度下降是可以预料的。硬盘驱动器不喜欢并行访问：每次读写头需要切换磁柱时，您都会损失几毫秒的时间。即使两个文件位于同一个磁柱上，甚至位于同一个磁道上，您仍可能需要等待一圈才能从一个文件移动到另一个文件。如果您以每秒兆比特为单位来衡量驱动器性能，那么随着并行访问的增加，该性能将呈指数下降。
fsck对此没有帮助：它仅修复目录结构的损坏，而不执行任何优化。
理想的解决方案是改用固态存储，因为它没有旋转盘片的任何物理限制。但这可能成本过高。
其次最好的方法是使用针对并行访问优化的 RAID。请记住，RAID 可以配置为许多不同的性能配置文件，因此您需要花一些时间来了解任何给定 RAID 硬件和驱动程序的设置。
您可以使用积极的文件系统缓存来减少问题。如果您的系统有足够的 RAM，Linux 应该已经做得相当好了。运行一个程序来top查看有多少可用 RAM。但如果最常用的文件不适合 RAM（或您可能获得的任何 RAM），这实际上不会有帮助。
穷人的解决方法是将文件分散到几个不同的物理硬盘上（而不仅仅是同一驱动器上的不同分区）。这不是一个真正长期可扩展的解决方案，最终会比一个像样的 RAID 花费更多。但如果您有闲置的驱动器，这可能是一个快速解决方案。
对于任何涉及硬盘驱动器的解决方案，请确保它们具有快速的旋转速度和低的寻道延迟。
我在这里写了一篇文章，介绍了一些有关硬盘性能的一般背景知识：
答案2
我预计 fsck 需要 5 个小时才能完成。
我反而会考虑（意味着：测试、测试、测试）迁移到 reiserfs。
答案3
- 不可以（fsck 可以修复损坏的文件系统元数据，但不能修复损坏的磁盘，也不是碎片整理工具）。
- 取决于文件系统。ext3 太长了，我得预留几个小时。ext4 或 xfs 等更现代的文件系统可以轻松快一个数量级。
答案4
hdparm 执行顺序读取。正如其他人所说，您的文件服务器磁盘应该执行大量寻道操作。
如果您收到 HD 错误，它们应该会出现在您的 /var/log/ 的某个地方。
为什么不试试“smartctl -t short /dev/sda”，然后再试试“smartctl -t long /dev/sda”？... 对于大多数新硬盘，即使在使用硬盘时也可以发出此命令。Smart 会给你一些结果。你可以使用“smartctl --all /dev/sda”读取硬盘的健康状况。
如果您将 hdparm 发送到安装了并发访问的 HDD，这可能是导致结果比以前少很多的原因。
我应该尽快将您的数据移至 RAID 设置。