Нет свободного места на диске

У меня странная ситуация, потому что команда Linux df говорит, что нет свободного места на диске

[root@backup cache]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3              72G   70G     0 100% /
/dev/sda1             190M   11M  170M   7% /boot
tmpfs                 248M     0  248M   0% /dev/shm

но du -sh /* говорит

[root@backup cache]# du -sh /*
4.0K    /bacula-restores
7.4M    /bin
5.4M    /boot
3.6T    /data
116K    /dev
55M     /etc
204K    /home
76M     /lib
16K     /lost+found
12K     /media
0       /misc
16K     /mnt
8.0K    /mount
0       /net
8.0K    /opt
0       /proc
2.3G    /root
32M     /sbin
8.0K    /selinux
168K    /share
8.0K    /srv
0       /sys
361M    /test
20K     /tmp
3.2G    /usr
1.5G    /var

Не могли бы вы сказать мне, где проблема? Где мое место? Я не могу понять это:(

9 ответов

Пытаться:

$ lsof +L1 

При этом будут найдены файлы с числом ссылок меньше 1 (файлы удалены, но все еще пишутся).

Для тех времен, когда du и d f не совпадают.

Short version: Use lsof to find the file that is unlinked but still open. Restart the application holding the file (or the whole system, if you are lazy) and you will get your free space back.

Длинная версия: Скорее всего, у вас есть файл, который открывается приложением и записывается в него, но был удален (удален) из файловой системы.

В отличие от NTFS у вас есть своего рода подсчет ссылок в ext. Это означает, что когда вы удаляете файл, вы просто удаляете ссылку на него. Открытие файла в программе добавляет ссылку. Таким образом, вам придется выяснить, какая программа содержит файл. Вот почему вы часто видите ссылки на ссылку / отсоединение, когда речь идет о файловых операциях в UNIX. Как правило, поиск файла выполняется с помощью инструмента. lsof,

Хорошая сторона этого поведения заключается в том, что вы никогда не получаете сообщение об ошибке "Файл открыт, поэтому вы не можете его удалить", которое часто появляется в Windows. Вы также можете заменить системные файлы, такие как общие библиотеки, и ваше программное обеспечение будет использовать старые библиотеки до тех пор, пока оно не перезапустится (и загрузит новые с диска), вместо того, чтобы перезагружаться для обновления программного обеспечения (снова Windows). Плохая сторона, которую вы видите прямо сейчас. Размер видимых файлов в файловой системе обычно не соответствует объему данных на диске.

Или бедняк lsof в этом случае будет (для Linux)

ls -l /proc/*/fd/ | grep deleted

Я всегда делаю "chattr +i /mount-point" в пустой директории, пока она не смонтирована.

Если случается, что что-то пытается записать туда, пока оно не смонтировано, возвращается сообщение об ошибке "Отказано в доступе". И вы сразу заметили ошибку.

Если в "/ mount-point" есть правильно смонтированный ресурс, то "chattr + i" не действует и все работает как положено.

Вы также можете проверить, не исчерпаны ли ваши иноды. df -i,

Я знаю, что пошло не так. У меня NFS смонтирована как /data, NFS имеет сетевое соединение с ошибкой и / data был на диске, смонтирован как / а не как общий ресурс NFS.

Я думал, что это может быть связано с таким механизмом

Пример списка dir: / /a [dir] file1 file2 /b [dir]

другое устройство: / fileX fileY

Если мы смонтируем "другое устройство" в / a, мы получим доступ к этому устройству через каталог /, но оригинал / a все еще существует, но перезагружен. Мы можем получить доступ к исходному каталогу после размонтирования последнего подключенного устройства. Это интересная собственность, но на самом деле может принести некоторые неприятности (не мое в данный момент).

У меня была точно такая же проблема, когда файлы на моем диске были относительно маленькими, но дисковое пространство было использовано на 100%. У меня была проблема, когда мой основной загрузочный диск заполнялся после выполнения синхронизации резервных дисков.

>rsync -avxHAXW /media/backup1 /media/backup2

После этой синхронизации мой основной диск был заполнен.... что меня озадачило. Оказывается, я случайно копировал файлы на загрузочный диск, а не на резервную копию2. Я исправил ошибку, удалил массивный файл с моего основного диска и перезапустил rsync. Даже после размонтирования и перемонтирования моих резервных дисков на моем загрузочном диске не хватило места. Я даже пытался очистить большие файлы на моем загрузочном диске....

>find . -type f -print0 | xargs -0 du -s | sort -n | tail -25 | cut -f2 | xargs -I{} du -sh {}

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

>empty-trash

После всей этой работы... диск все еще заполнен. Я решил перезагрузить машину. После перезагрузки мой раздел загрузочного диска изменился с 100% до 10%! Похоже, что процесс rsync должен продолжаться в фоновом режиме, удерживая ресурсы диска.

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

  • Вы можете попытаться уменьшить зарезервированное пространство корня мысли tune2fs
  • Контролируйте свою сеть с другого компьютера, чтобы проверить, использует ли какой-то скрытый злой процесс ваш компьютер в качестве сервера для трафика варез
  • если у вас есть монолитное ядро, попробуйте перезагрузить его, это должно отключить руткит LKM, если он есть
  • запустить рхунтер, чкрооткить
  • перезагрузитесь с живым дистрибутивом и проанализируйте диск из оперативной памяти

В дополнение к уже предложенным причинам, это может быть также следующим:

  • другой диск монтируется "поверх" существующей папки, которая полна данных
  • du подсчитает размер потраченного монтированного диска, а df покажет реально потраченный
  • Решение: (когда это возможно) размонтировать все некорневые диски и проверить размер с помощью du -md 1 очередной раз. Исправьте ситуацию, переместив скрытую папку в другое место или смонтировав ее в другом месте.
Другие вопросы по тегам