Что пожирает мое дисковое пространство?

Я использую Linux Mint 14 Nadia. Раздел Linux имеет 10G. При запуске системы duсообщает об использовании 80%. Затем использование медленно растет, пока не достигнет 100%, и система станет непригодной для использования. (Это может происходить порядка дней или недель). После перезагрузки использование сбрасывается до 80%.

Самое странное, что это не duпоказывает никаких изменений.

Вот вывод этих команд (разделы Windows и внешнего диска исключены):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Примечание: я использую спящий режим. После спящего режима использование остается прежним, а после перезагрузки сбрасывается до 80%.)

Как мне отследить, что съедает пространство?

Я прочитал этот вопрос . Я все еще в темноте. Как узнать, какая программа отвечает за это поведение?

После редактирования : нашел его. Пространство заявлено журналом ядра, который виден dmesg. Он заполняется, потому что моя машина генерирует ошибки со скоростью 5 в секунду. (Это связано с этой ошибкой .) Пусть будущие читатели с похожей проблемой - медленно заполняющим пространство на диске, незаметно для себя du- не забудут попробовать dmesgпоискать причину.

Повторное исполнение

sudo du -x   -d1 -h /

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

невидимые файлы

Если duэти файлы не отображаются, то одной из возможностей являются удаленные файлы. Файл (или, скорее: его имя, то есть его запись в каталоге) может быть удален, пока файл все еще используется. Пока существует правильный файловый дескриптор, указывающий на этот файл, он покрывает пространство на томе (если это не пустой файл ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Вы можете найти эти файлы с find:

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Это может быть один большой файл или несколько файлов меньшего размера, которые вызывают вашу проблему. Сейчас в моей системе около 30 таких файлов (принадлежащих только пяти процессам). ls -lпоказывает размер этих файлов, но, кажется, получить это значение невозможно find.

После завершения процесса пространство dfснова становится доступным для файловой системы ( ).

Используйте что-то вроде

lsof -s | grep deleted | sort -k 8

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

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

После этого, если вы найдете процесс, который, вероятно, является виновником, мы увидим, как это исправить.

find / -size +10000k -print0 | xargs -0 ls -l -h

Используйте это, чтобы найти рекурсивно то, что заполняет более 10 МБ + из /(root), и отобразить его с большим количеством деталей с помощью ls -lin xargs. Если вы напишите 1000000 (2 дополнительных нуля), вы можете получить, например, 1 ГБ +.

du / -h --max-depth=1 | sort -h

Вы также можете использовать du, и просто копаться в нем вручную.

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

Сначала загляните /var, затем /home.

$ sudo du -x -d1 -h /var  | sort -hr`

$ sudo du -x -d1 -h /home | sort -hr`

Вы также можете сузить фокус до подкаталогов в любом из этих мест. После того, как вы устали смотреть туда, я обычно перехожу к /root, и, наконец, к остальным подкаталогам /.

Если это дистрибутив на базе Red Hat, кеш, который yumиспользуется для обновления, может занимать много места. Вы можете использовать эту команду, чтобы очистить ее:

$ yum clean packages

Другие используемые дистрибутивы aptмогут делать что-то подобное apt-get clean.

Я также выполнил бы эту команду в верхней части вашего /каталога, это место иногда может стать источником для блуждающих файлов журнала.

$ ls -la /

Обратите особое внимание на точечные файлы! Вещи названы .blah, например.

timeshift ел мой диск.

sudo timeshift -delete--all

Восстановил 50Gb.

У меня почти такая же ситуация.

В моем случае причиной была VMware. Один из других VMware на той же машине, он занимал дисковое пространство. Вот почему мое дисковое пространство было 100%.

После удаления больших файлов из соседнего VMware, он работает правильно.