Root пишет на ext4, а сервис уже нет: проверяем резерв блоков

На почти полном ext4-томе обычный сервис перестал создавать файлы, но команда администратора ещё может записать небольшой файл. Возникает подозрение на права. Один из возможных механизмов — зарезервированные блоки: часть пространства оставлена для назначенного привилегированного пользователя или группы.

Убедиться, что речь об ext4

findmnt -T /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS
df -B1 /srv/data
df -i /srv/data

Если тип другой, не используйте tune2fs по привычке. Также исключите исчерпание inode и пользовательские квоты. У ошибки записи несколько независимых причин; наличие резервных блоков — ещё не доказательство, что именно они ограничили приложение.

Предположим, df показывает около 5 ГиБ свободных блоков в общем подсчёте, но почти нулевое Avail для обычной записи. На томе с резервом это правдоподобно. Проверка от root не воспроизводит условия сервисного пользователя и может скрыть проблему. Сохраните точный системный код ошибки приложения.

Прочитать настройки устройства

tune2fs -l /dev/mapper/vg-data

Устройство в примере нужно заменить значением SOURCE из findmnt и проверить, что это правильный ext4-том. В списке интересны Block count, Reserved block count, Block size, Reserved blocks uid и gid. Команда -l читает свойства; остальные параметры tune2fs могут изменять файловую систему, поэтому не переносите их из случайной инструкции.

Если Reserved block count=1310720, а Block size=4096, резерв составляет 5368709120 байт, то есть 5 ГиБ. Рассчитывайте по фактическим числам, а не по предположению о стандартных пяти процентах. Текущая конфигурация могла меняться после создания и расширения тома.

Зачем сохранять запас

На системном томе резерв помогает сохранить возможность административной работы при заполнении обычными пользователями. Изменение до нуля ради краткого освобождения места может лишить систему этого запаса. Для отдельного большого тома данных подходящая политика бывает иной, но её выбирают с учётом характера записи, фрагментации и аварийного обслуживания.

Параметры -m и -r управляют резервом в процентах или блоках; их назначение описано в tune2fs. Изменять резерв следует как отдельное согласованное действие после проверки устройства и плана возврата. Не используйте команду с уменьшением как универсальную реакцию на заполненный корневой раздел.

Устранить рост данных

Даже обоснованное уменьшение резерва даёт разовый запас. Если журналы или результаты увеличиваются на гигабайт в час, проблема вернётся. Найдите источник роста, определите retention, расширение тома или перенос данных. Временной резерв полезен только вместе с планом управления потреблением.

После действия повторите df и штатную запись от пользователя службы. Проверьте, сколько пространства доступно именно ему, и установите порог предупреждения до исчерпания Avail. В отчёте сохраните прежний и новый резерв, арифметику объёма и время повторного заполнения при текущем темпе роста.

Посмотрите программу Linux и Bash для DevOps-инженеров. Диагностика дисков, пользователей и сбоев сервиса помогает рассматривать свободное место как доступный приложению ресурс, а не одну общую цифру.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён