文件系统几乎满是坏事吗？

Question

示例我有大/小文件系统JFS2/EXT3，无论（以及各种操作系统、Linux、AIX），但其中一些是例如：90%、95%、98% 的使用率。

问题：文件系统几乎满了会不会有什么坏处？性能问题或 FS 损坏或硬件问题？

更新：

• 问题是关于企业环境。有没有人有关于效果的真实文章/网址？:)

• “这些文件系统上有哪些目录？” - 任何，例如：SAP、ORACLE 等。

• 磁盘通常来自 SAN。

Answer 1

文件系统不会仅仅因为它已满而中断，因此从文件系统的角度来看没有问题。一旦文件系统接近满，文件更有可能碎片化，性能问题可能取决于文件系统，但这通常并不重要。

在真正的问题是，在一个完整的文件系统，任何写操作将失败。所以这取决于将尝试在这样的文件系统上写入什么。

许多程序必须能够写入/保存数据才能正常运行。因此，如果您的文件系统在尝试写入时已满，您将在应用程序层遇到数据丢失或损坏的情况。“我试图保存您的数据，但不能”是许多程序处理得不好的情况。最坏的情况是程序会在注意到没有足够的空间容纳新的保存文件之前就开始覆盖旧的保存文件，所以你丢失了两个文件。

对于系统关键的事情（例如，在启动/关闭时发生的任何写入、日志记录工具等），完整的文件系统在最坏的情况下可能会使您的系统无法正常运行；出于这个原因，ext* 文件系统有一个根保留，以便在其他一切都已满时允许系统事物（根）一些可用空间。在这种情况下，您应该提供一些额外的存储空间或删除一些旧的东西。

Answer 2

从生产的角度来看，这是一种糟糕的状态。首先，随着磁盘使用量的增加，性能会下降。当磁盘接近满容量时，磁盘中存储数据的连续区域较少。由于额外的磁盘寻道和等待空闲扇区到达磁盘磁头的延迟效应，这会影响性能。

更重要的是对系统的潜在影响。服务器是否提供重要服务？开发和运营团队需要多长时间才能意识到服务已关闭？没有服务时，用户多久会生气？当没有要写入的存储时，应用程序通常会冻结。可能会产生连锁反应，导致进一步的问题——在服务完全恢复之前增加更多时间。并且当服务恢复后，系统状态可能会不平衡——例如，服务停机期间大量积压的传入数据会导致处理延迟。

Answer 3

如果这是“静态”数据库存储，则填充它没有什么坏处 - 特别是当数据库的自动扩展关闭时。其他任何事情都会浪费宝贵的 SAN 空间。可以关闭这些文件系统的监控，或者将警告级别提高到 99% 甚至 100%。

这仅适用于非增长数据，因此日志应该放在其他地方。不过，应该密切监视日志存储。而且它应该足够大，以便管理员可以及时对监控发出的警告做出反应。