Как проверить свободное место на диске

Что проверяют

Не знание флага -h, а умение довести диагностику до конца. Разница между «места нет на файловой системе» и «места нет по другой причине» (кончились иноды, файл удалён, но держится открытым, распух слой контейнера) отделяет админа от человека, выучившего одну команду.

Как отвечать

• df -h показывает занятость смонтированных ФС, df -hT добавляет тип, df -i показывает иноды: при россыпи мелких файлов место есть, а создать файл нельзя.
• Дальше ищем виновника сверху вниз: du -xh --max-depth=1 /var | sort -h. Ключ -x не даёт уйти на другую ФС.
• Классическая ситуация: df показывает 100%, сумма du заметно меньше. Значит файл удалён, но открыт процессом, и место вернётся только после закрытия дескриптора. Ищем через lsof +L1, лечим рестартом процесса или truncate -s 0 /proc/PID/fd/N.
• Типичные пожиратели: журнал systemd (journalctl --disk-usage, чистка journalctl --vacuum-size=500M), Docker (docker system df, затем docker system prune), незаротированные логи, дампы и старые ядра.
• В Windows wmic объявлен устаревшим и в свежих сборках отключён, современный вариант это PowerShell:

Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID, Size, FreeSpace

• Мониторинг: node_exporter плюс алерт не на текущий процент, а на прогноз через predict_linear, чтобы узнать за сутки, а не по факту падения.

Где спотыкаются

Останавливаются на df -h и не могут объяснить расхождение с du. Про открытые дескрипторы удалённых файлов вспоминают редко, хотя это самый частый инцидент с логами.

Забывают про иноды и про 5% блоков, зарезервированных под root (tune2fs -m): запись от обычного пользователя падает, когда df показывает свободные гигабайты.

Предлагают apt-get autoremove как основную чистку. На сервере она освобождает десятки мегабайт, а проблема почти всегда в /var/log, /var/lib/docker или дампах.

Чистят лог командой rm при работающем демоне: место не возвращается. Нужен truncate -s 0 или ротация с сигналом процессу.