我正在使用符合 PCI 分区规则的服务器，这意味着以下每个目录都有自己的分区：/、/var、/boot、/usr、/tmp 和 /home。该服务器目前正在使用 Apache / MySQL 后端托管一个网站。
我收到一条警告，说 /var 分区（大小为 2 GB）空间不足。我检查了一下，位于 /var/log/access.log 的 Apache 访问日志生成了大量文本：在没有设置日志轮换的情况下，大约 10 天内生成了 1 GB 左右的文本。
我重新配置了 Apache 设置，将日志放在具有更多空间的另一个分区上，并使用 gzip 压缩设置日志轮换。
奇怪的地方就在这里。旧的 Apache 访问日志位于 /var/log/access.log，未压缩时大约有 920 MB。/var 分区大约已满 80%，因此它使用了 2.0 GB 中的 1.6 GB。
我运行以下命令来压缩日志文件：
cd /var/log && gzip -9 access.log > access-2011-12-19.log.gz
我现在意识到我对 gzip 的使用有点生疏了，因为它创建了两个文件：access-2011-12-19.log.gz（空文件）和 access.log.gz（现在为 68 MB，包含原始的 920 MB 日志文件）。我删除了 access-2011-12-19.log.gz 文件，旧的日志文件现在不见了。
问题：然后我检查了 /var 分区上的空间，令我困惑的是，现在显示为 78% 已满，或大约 1.4 GB。
似乎将 920 MB 的日志文件压缩到 68 MB 应该可以节省大量磁盘空间，但事实似乎并非如此。可能是什么问题？如果有帮助的话，服务器正在运行 CentOS 6。
答案1
完成后多久gzip检查磁盘使用情况？ping 的最后一步gzip是删除原始文件。删除大型文件后，文件系统可能需要很长时间才能追踪并释放所有关联的 inode。我有时看到它需要几个小时，尽管那是在比你的文件大得多的文件上。
编辑后添加：另一种可能性是某个进程仍处于打开access.log状态；甚至 Apache 可能仍在写入它？即使您从文件系统取消链接（“删除”）文件，只要有指向它的打开文件描述符，它就不会真正被删除。
另外，我应该提到——如果你想gzip将压缩文件（或解压文件）写入标准输出，而不删除未压缩的原始文件（或压缩的原始文件），你可以指定该-c选项。或者，你可以在标准输入上发送原始文件，而不是将其名称作为参数传递。因此，以下任一操作均可：
gzip -c -9 access.log > access-2011-12-19.log.gz
gzip -9 < access.log > access-2011-12-19.log.gz
（我个人倾向于使用后一种方法。）