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

16
  

df

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

Вчера 77% составляли всего 60%, и через несколько дней оно заполнится до 100%.

Я уже некоторое время наблюдаю за фильтрами:

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

Это давало мне (более или менее) одинаковые цифры каждый день. Общее количество 14G меньше половины размера диска. Куда идет отдых?

Мои знания в Linux не намного глубже.

Возможно ли, чтобы файлы не отображались здесь? Возможно ли распределить пространство любым другим способом?

    
задан nizzle 24.09.2015 в 08:59
источник

2 ответа

27

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

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

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

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

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

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

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

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

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

    
ответ дан muru 24.09.2015 в 09:59
источник
2

Чтобы добавить отличный ответ от muru:

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

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

Если у вас, скажем, 1'000'000 (1 миллион) крошечных 1-байтных файлов, du будет считать это как 1'000'000 байт, скажем 1Mb (... purists, пожалуйста, не съеживайтесь)

Но на диске каждый файл состоит из двух вещей:

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

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

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

    
ответ дан Olivier Dulac 24.09.2015 в 18:48