raidshadowlegend

Так, у нас тут есть какие-то зарезервированные блоки. Для того, чтобы прояснить что за блоки нам встретились, вновь обратимся к Linux API исчерпывающее руководство от Майкла Керриска, стр. 312 (просто удобно делать все отсылки к одной книге, хотя в Advanced Programming in the Unix Environment про это тоже можно почитать)

Многие «родные» файловые системы UNIX и Linux поддерживают представление о резервировании некоторой части блоков файловой системы для суперпользователя на тот случай, когда файловая система становится заполненной. Суперпользователь по-прежнему может войти в систему и принять меры по устранению данной проблемы. Если в файловой системе есть зарезервированные блоки, то разность значений полей f_bfгее и f_bavail в структуре statvfs сообщит нам, сколько блоков зарезервировано.

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

Теперь давайте слегка изменим настройки файловой системы, чтобы у нас появился небольшой запас пространства, и немного времени на решение проблемы:

Отлично, теперь есть немного места, и можно более-менее в штатном режиме начать поиск решения.

Заключение

• многие файловые системы резервируют дисковое пространство для суперпользователя. Это механизм защиты, позволяющий поддерживать работу системы (и разрешать администратору вход в систему), когда на диске не осталось свободного места.

• объем зарезервированного пространства можно изменить. Это сделает некоторое количество блоков пригодными для использования и поможет вам выиграть немного времени. Но будьте осторожны, вам все равно нужно проанализировать, что происходит, и исправить это должным образом.

• на больших файловых системах (>50–100 ГБ) резервирование 5% является излишним. Так что возможно вы захотите проверить свою файловую систему и уменьшить количество зарезервированных блоков (однако к любому тюнингу и оптимизации нужно подходить с умом и без фанатизма).

Тут возникает вопрос. А как из каталога размером 12 мегабайт получился архив на 426 мегабайт, который занял всё место?
Давайте глянем, какой самый большой файл располагается в каталоге /var/lib/docker:

Интересно, откуда у нас образовался 100 гиговый файл на разделе размером в 5 гигабайт?

Копнём дальше:

Наиболее вероятно, дальнейшее гугление симптомов приведёт вас на страничку wiki, посвящённую разрежённым файлам. И да, здесь мы имеем дело именно с ними (Unix - Профессиональное программирование, стр 157, или М.Керриск - Linux API исчерпывающее руководство, стр. 118).

Да, в описываемом случае Docker использовал в качестве драйвера хранилища Devicemapper, который на данный момент устарел (рекомендуется использовать или overlay2 или fuse-overlayfs для rootless режима). Однако в целом использование разрежённых файлов довольно распространённое решение для хранения файловых систем в файлах, поэтому для devicemapper оно не уникально, и может встречаться достаточно часто.

Заключение

• Большинство современных файловых систем поддерживают разрежённые файлы. Полный список доступен на вики.

• Разрежённые файлы - это файлы которые не используют блоки до тех пор, пока туда не будут записаны данные.

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

где:

указывает что нужно искать на машине все объекты с типом файл

Эта часть распечатает «разреженность» файла и его полное имя.

На этом этапе вывод будет выглядеть примерно так:

Если первое число меньше 1.0, то файл считается «разреженным».

Дальше мы фильтруем вывод с помощью awk:

и получаем список разрежённых файлов.

• Файлы можно конвертировать в разрежённые и обратно

• Некоторым утилитам (tar, rsync) нужно передать дополнительные аргументы (например "--sparse" для tar) для работы с разрежёнными файлами

Чтобы уменьшить количество выводимых данных (например чтобы убрать из вывода tmpfs или squashfs), применим опцию "-x" к df:

В любом случае здесь очевидно, что дисковое пространство полностью исчерпано. Давайте найдём виновного:

У du тоже есть полезная опция "-x", здесь она выполняет задачу исключения из вывода точек монтирования других файловых систем.

Общее пространство, занимаемое корневым разделом, составляет 4,2Gb. То есть у нас должно быть примерно 700Mb свободного места (15% от общего объема). Давайте перепроверим:

Всё так же. Значения в выводах df и du не совпадают:

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

В выводе команды lsof выше мы можем видеть, что логи сервера Apache хоть и были удалены, но всё еще заняты процессом (М.Керриск - Linux API исчерпывающее руководство, стр. 379). Особенно часто это происходит из-за неправильно настроенного logrotate. Иногда logrotate удаляет журнал, не сообщая процессу, что ему необходимо закрыть файловый дескриптор. Мы можем получить доступ к данным через /proc/$PID/fd/$DESCRIPTOR_NUMBER:

Поскольку данные всё еще там, мы можем их восстановить (кстати еще это может оказаться полезным если вы случайно удалите файлы mysql, тут только главное чтоб сервис был запущен).

Есть пара возможных вариантов решения:

1. Вы можете перезапустить сервис, и дескриптор будет освобождён.

2. Или усечь длину файла до нуля, с помощью truncate:

Проверяем:

Отлично. Проблема решена.

Заключение

• Процесс (в нашем случае Apache) вызвал системный вызов open, и получил дескриптор файла для работы с ним. Поскольку это файл журнала, он не был закрыт сразу.

• Тем временем какой-то другой процесс (или тот же самый) пытался удалить файл (вызвал системный вызов unlink).

• Это уменьшило счетчик ссылок в индексном дескрипторе до нуля, и файл исчез из дерева файлов.

• Однако ядро не смогло освободить блоки, поскольку всё еще существовал открытый дескриптор, ссылающийся на индексный дескриптор.

• Как итог у нас есть два возможных решения такой проблемы — обрезать файл или закрыть дескриптор.

P.S. Извиняюсь за картинки. Так и не понял, как здесь можно вставлять stdout без потери форматирования. Если кто-то в комментах подскажет - будет супер.