Почему может не отчиститься место после удаления файла?

Причины, по которым место на диске может не освобождаться после удаления файлов

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

1. Файл занят запущенным процессом (File Handle)

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

Как проверить:

# Поиск процессов, удерживающих удалённые файлы
sudo lsof | grep deleted

# Более конкретный поиск
sudo lsof +L1  # Показывает файлы с link count = 0 (удалённые)

# Для определённого раздела
sudo lsof /var/log | grep deleted

Пример вывода:

apache2   1234   www-data    5u      REG    8,1    10485760     12345 /var/log/apache2/access.log (deleted)

Здесь процесс Apache с PID 1234 держит открытым удалённый файл /var/log/apache2/access.log.

Решение: Перезапустить процесс или вручную закрыть дескриптор:

# Перезапуск службы
sudo systemctl restart apache2

# Или отправка сигнала процессу
sudo kill -HUP 1234

# Или принудительное закрытие дескриптора через gdb (крайняя мера)
sudo gdb -p 1234 -ex "call close(5)" --batch

2. Жёсткие ссылки (Hard Links)

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

# Создание жёсткой ссылки
ln original.txt hardlink.txt

# Проверка количества ссылок
ls -li original.txt hardlink.txt
stat original.txt

# Удаление original.txt не освободит место, пока существует hardlink.txt

3. Смонтированные файловые системы и bind-mounts

Если файл находился в смонтированной файловой системе (например, NFS, или bind-mount), удаление может вести себя неочевидно. Особенно коварны overlayfs (используется в Docker) и bind mounts.

# Проверка всех смонтированных файловых систем
mount | grep -E "(overlay|bind|nfs)"

# Для Docker контейнеров
docker ps --format "{{.Names}}" | xargs -I {} docker inspect {} | grep -A5 Mounts

4. Дисковые квоты (Quotas)

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

# Проверка квот
sudo repquota -a
sudo quota -u username

5. Файловая система с отложенным удалением (Lazy Removal)

Некоторые файловые системы (например, ZFS с включённым snapshots, или Btrfs) могут использовать отложенное освобождение места. В ZFS, пока существует снапшот, данные, на которые он ссылается, не могут быть физически удалены.

# Для ZFS
sudo zfs list -t snapshot
sudo zfs destroy pool/dataset@snapshotname

6. Незавершённые операции ввода-вывода

Если в момент удаления файла система выполняла с ним операции (например, логирование или синхронизацию на блочном уровне), освобождение места может быть отложено.

7. Проблемы с файловой системой

В редких случаях повреждение файловой системы может привести к некорректному учёту свободного места. Поможет проверка:

# Для ext4
sudo umount /dev/sda1
sudo fsck -y /dev/sda1
sudo mount /dev/sda1

8. Docker и контейнеры

В Docker частой причиной является использование overlay2 драйвера хранения. Удалённые файлы внутри контейнера могут не освобождать место на хосте из-за разделяемых слоёв или если контейнер продолжает работать.

# Очистка неиспользуемых данных Docker
docker system prune -a --volumes

# Проверка использования диска Docker
docker system df

Практическая диагностика

Алгоритм диагностики, который я применяю:

1. Проверить использование места:

   df -h
   du -sh /путь/к/директории
   

2. Найти удалённые, но открытые файлы:

   sudo lsof +L1 | head -20
   

3. Проверить журналы ядра:

   sudo dmesg | grep -i "disk\|space\|full"
   

4. Мониторинг в реальном времени:

   # Использование inotify для отслеживания изменений
   sudo inotifywait -m -r /var/log 2>/dev/null
   

5. Использовать специализированные утилиты:

   # ncdu для анализа использования диска
   ncdu /var
   
   # fatrace для отслеживания файловых операций
   sudo fatrace
   

Профилактика:

• Использовать logrotate с опцией copytruncate или postrotate скриптами для перезапуска служб
• Настроить мониторинг свободного места (Prometheus + node_exporter)
• Для критичных сервисов использовать отдельные разделы с квотами
• Регулярно чистить временные файлы и кэши

Понимание этих механизмов критически важно для DevOps-инженера, так как неосвобождающееся дисковое пространство часто приводит к инцидентам в production-среде, особенно на серверах с интенсивным логированием или обработкой временных данных.