Назад | Перейти на главную страницу

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

У меня странная ситуация, потому что команда 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

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

Пытаться:

$ lsof +L1 

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

Для тех случаев, когда du и df не совпадают.

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

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

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

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

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

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

Я всегда выполняю «chattr + i / mount-point» для пустого каталога, когда он отключен.

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

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

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

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

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

пример списка каталогов: / / a [каталог] файл1 файл2 / b [каталог]

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

Если мы смонтируем «другое устройство» в / a, мы получим доступ к этому устройству через каталог / 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, если он есть
  • запустить rkhunter, chkrootkit
  • перезагрузитесь с живым дистрибутивом и проанализируйте диск из ОЗУ

Помимо уже предложенных причин, это могут быть следующие:

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