Диск / dev / root заполнен, но не может определить причину
Мне нужна помощь, чтобы исправить проблему с дисковым пространством. На самом деле я использую частный облачный сервер VPS с 50 ГБ дискового пространства.
Когда я запускаю df -h, я получаю:
Filesystem Size Used Avail Use% Mounted on
/dev/root 48G 45G 570M 99% /
devtmpfs 2.0G 4.0K 2.0G 1% /dev
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 395M 524K 395M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 2.0G 0 2.0G 0% /run/shm
none 100M 0 100M 0% /run/user
df -i возвращает:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 3141600 78065 3063535 3% /
devtmpfs 505084 1438 503646 1% /dev
none 505206 2 505204 1% /sys/fs/cgroup
none 505206 891 504315 1% /run
none 505206 2 505204 1% /run/lock
none 505206 1 505205 1% /run/shm
none 505206 2 505204 1% /run/user
Но когда я бегу du -sh / | sort -nr | head, я получаю:
du: cannot access â/sys/kernel/slab/L2TP/IPv6â: No such file or directory
du: cannot access â/sys/kernel/slab/L2TP/IPâ: No such file or directory
du: cannot access â/proc/391/task/391/fd/4â: No such file or directory
du: cannot access â/proc/391/task/391/fdinfo/4â: No such file or directory
du: cannot access â/proc/391/fd/4â: No such file or directory
du: cannot access â/proc/391/fdinfo/4â: No such file or directory
du: cannot access â/proc/402â: No such file or directory
du: cannot access â/proc/32350â: No such file or directory
du: cannot access â/proc/32354â: No such file or directory
du: cannot access â/proc/32356â: No such file or directory
du: cannot access â/proc/32360â: No such file or directory
du: cannot access â/proc/32363â: No such file or directory
du: cannot access â/proc/32368â: No such file or directory
8.9G /
Итак, я знаю, что обе команды не возвращают одинаковую информацию. Первый возвращает использование диска файловой системы, другой - пространство, используемое файлами.
Нет установленного привода или устройства, а вес бревен ~ 167M.
Я попытался cat /proc/mounts, который возвращает:
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=2020336k,nr_inodes=505084,mode=755 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run tmpfs rw,nosuid,noexec,relatime,size=404168k,mode=755 0 0
none /sys/fs/pstore pstore rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0
systemd /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,name=systemd 0 0
Итак, я могу определить, что занимает столько места, так как мой du кажется нормальным? Я попробовал autoclean и autoremove без шансов, все в порядке.
Кстати, у меня также есть cron, который запускает datas и mysql dump и отправляет его в Dropbox. Но 7 папок (резервное копирование на 7 дней) занимают только 1,7 ГБ дискового пространства.
2 ответа
У Вас есть какие-либо другие разделы, которые Вы иногда монтируете? Я просто попытался помочь парню с подобной проблемой несколько часов назад: 14,04 дисков монтируют, что проблема возникла нашу левую сторону поля , Как мы узнали вместе, он когда-то смонтировал раздел для резервного копирования, и это отказало (сбой питания, я думаю). После этого раздел так или иначе остался в смонтированном состоянии как недоступная папка в/media/и также рассчитал к информации об использовании диска. Он наконец просто удалил поврежденную точку монтирования для решения проблемы.
, Таким образом, у Вас также есть какое-либо мертвое монтирование? Тогда можно попытаться удалить их (резервное копирование всегда рекомендуется! Я не беру на себя ответственности за в конечном счете поврежденные данные!).
OP заявила
, я понял это.
На самом деле я использовал сценарий для запуска резервного копирования и синхронизации к Dropbox моих файлов приложения. Вещи: у Меня есть синхронизирующий сценарий, который говорит то, что является приложением, чтобы получить резервные копии от, затем синхронизировать его к Dropbox. Но эти синхронизация является оба путем .
И временные синхронизирующие файлы находятся в той же папке как синхронизирующий сценарий. По неизвестной причине сценарий выполнялся многократно вместо однажды (вероятно, плохая конфигурация крона). Таким образом, каждый экземпляр использовал некоторое дисковое пространство для синхронизации, и у меня наконец закончилось дисковое пространство.