Странная проблема с GZip / дисковым пространством

Question

Я работаю на сервере, который использует правила разбиения PCI Compliant, что означает, что у каждого из следующих каталогов есть свой собственный раздел: /, /var, /boot, /usr, /tmp и /home. В настоящий момент сервер обслуживает веб-сайт с бэкэндом Apache / MySQL.

Я получил предупреждение о том, что разделу /var (размер которого составляет 2 ГБ) не хватает места. Я проверил, и журнал доступа Apache, расположенный по адресу /var/log/access.log, генерировал нелепое количество текста: примерно 1 ГБ за 10 дней без настройки ротации журнала.

Я перенастроил настройку Apache, чтобы поместить журналы в другой раздел с большим пространством, и я настроил вращение журналов со сжатием gzip.

Вот странная часть. Старый журнал доступа Apache находился по адресу /var/log/access.log и содержал около 920 МБ несжатого файла. Раздел /var был заполнен примерно на 80%, поэтому он занимал 1,6 ГБ из общего объема 2,0 ГБ.

Я запустил следующую команду, чтобы сжать файл журнала:

cd /var/log && gzip -9 access.log > access-2011-12-19.log.gz

Теперь я понимаю, что немного устарел с использованием gzip, потому что он создал два файла: access-2011-12-19.log.gz, который был пуст, и access.log.gz, который теперь составлял 68 МБ и содержал оригинальный файл журнала 920 МБ. Я удалил файл access-2011-12-19.log.gz, и старый файл журнала теперь исчез.

Проблема: я тогда проверил пространство в разделе /var, и, к моему замешательству, теперь читаю как полный 78%, или около 1,4 ГБ.

Кажется, что сжатие файла журнала 920 МБ до 68 МБ должно сэкономить много места на диске, но, похоже, этого не произошло. В чем может быть проблема? На сервере работает CentOS 6, если это поможет.

Answer 1

Как долго после завершения gzip вы проверяли использование диска? Последний шаг gzip ping - удаление исходного файла. После удаления огромного файла файловой системе может потребоваться некоторое время, чтобы отследить и освободить все связанные 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

(Я склонен использовать последний подход, лично.)