Диск медленно заполняется, но нет видимых изменений размера файла

Если бы существует невидимый рост в дисковом пространстве, вероятный преступник был бы удаленными файлами. В Windows, при попытке удалить файл, открытый чем-то, Вы получаете ошибку. В Linux файл будет отмечен, как удалено, но данные будут сохранены, пока приложение не отпускает. В некоторых случаях это может использоваться в качестве аккуратный способ вымыться после себя - сбои приложения не будут препятствовать тому, чтобы были убраны временные файлы.

Для рассмотрения удаленный, все еще используемые файлы:

lsof -b 2>/dev/null | grep deleted

у Вас может быть большое количество удаленных файлов - который сам по себе не является проблемой. Единственный удаленный файл, становящийся большим, является проблемой.

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

, Если Вы когда-нибудь видите что-то как:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

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

Файлы в /dev/shm являются объектами общей памяти и не занимают много места на диске (inode число самое большее, я думаю). Они могут также быть безопасно проигнорированы. Файлы, названные vteXXXXXX, являются файлами журнала от основанного на VTE эмулятора терминала (как Терминал GNOME, Терминатор, и т.д.). Эти мог быть большим, если у Вас есть окно терминала, открытое с партии (и я имею в виду партии ) производимого материала.

Добавить к превосходному ответу muru:

• df показывает размер на диске,
• , и du показывает общий размер содержания файлов.

, Возможно, то, что Вы не видите с du, является появлением многих, много маленьких файлов... (считайте последний столбец df -i и посмотрите, увеличивает ли количество inodes (т.е., файлов) много сверхурочного времени также)

, Если Вы, оказывается, имеете, скажем, 1'000'000 (1 миллион), крошечные 1-байтовые файлы, du будут считать это как 1'000'000-байтовое общее количество, скажем, 1 МБ (... пуристы, не съеживайтесь)

, Но на диске, каждый файл сделан из 2 вещей:

• 1 inode (указывающий на данные файла), и что inode может отдельно составить 16 КБ (!),
• И данные каждого файла (= содержание файла) помещается на дисковые блоки, и те блоки не могут содержать данные нескольких файлов (обычно...), таким образом, Ваш 1 байт данных займет по крайней мере 1 блок

Таким образом, миллион файлов 1 байта файлов займет 1'000'000'000 * size_of_a_block общее пространство для данных плюс 1'000'000'000 * size_of_an_inode из размера inode... Это может составить несколько Гбит использования диска для 1 миллиона "1-байтовых" файлов.

, Если у Вас есть 1 024-байтовые блоки, и еще 256 байтов inode размера, о Ваших 1'000'000 файлах сообщат как примерно 1 МБ на du, но рассчитают как примерно 1.25 ГБ на диск (как замечено df)! (или даже 2 ГБ, если каждый inode также должен быть на 1 блоке выделенного диска... Я не знаю, если это так)

Если /dev/vda1 заполняется, это могло бы быть вызвано Jenkins или Докером (или и т.д.), и Вам, возможно, придется использовать lsof управляйте, чтобы убрать журналы и установить, это - размер.