A unidade raiz do Ubuntu está ficando sem espaço, não consigo encontrar a fonte por meio de du ou lsof

Question

O drive raiz em uma máquina Ubuntu 15.10 está quase sem espaço, mas não consigo encontrar a fonte. A unidade que está ficando sem espaço é sdb2 , 313M de 51G disponíveis. O sistema de arquivos é ext4 .

Aqui está a sudo du -h / --max-depth=1 output:

Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           789M  9.4M  780M   2% /run
/dev/sdb2        51G   48G  313M 100% /
tmpfs           3.9G   12K  3.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sdb1       511M  3.4M  508M   1% /boot/efi
tmpfs           789M  8.0K  789M   1% /run/user/1000
/dev/sda1       239G  122M  239G   1% /media/DATA

Mas não consigo encontrar arquivos grandes. O uso total em / parece ser apenas 3,4 G. Aqui está a saída de sudo du -h / --max-depth=1 :

4.0K    /mnt
188K    /tmp
406M    /home
339M    /var
8.1M    /etc
361M    /lib
du: cannot access ‘/proc/7626/task/7626/fd/4’: No such file or directory
du: cannot access ‘/proc/7626/task/7626/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/7626/fd/3’: No such file or directory
du: cannot access ‘/proc/7626/fdinfo/3’: No such file or directory
0    /proc
13M    /bin
du: cannot access ‘/run/user/1000/gvfs’: Permission denied
9.4M    /run
1.6M    /root
4.0K    /lib64
16K    /lost+found
0    /sys
1.1M    /media
12K    /dev
222M    /opt
2.0G    /usr
62M    /boot
9.5M    /sbin
4.0K    /cdrom
8.0K    /srv
3.4G    /

Encontrei uma pergunta semelhante aqui: Sem espaço em disco, qual é a fonte

Nesse caso, parece que o problema foi causado por um log excluído que de alguma forma não foi fechado por um processo em execução, e a maneira de encontrá-lo foi executar sudo lsof | grep deleted . No meu caso, a saída é

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.

Além disso, o problema persiste após a reinicialização do sistema, portanto, é improvável que essa seja a causa.

Outra solução sugerida é desmontar /var/lib/ureadahead/debugfs , mas hesito em fazer isso.

O que mais poderia estar errado?

    

Answer 1

Bem, é apenas um palpite, mas pode funcionar: Acho que o usuário uma vez esqueceu de montar /dev/sda1 as /media/DATA e todos os dados foram gravados em /dev/sdb2 em vez de /dev/sda1 .

Para verificar isso, desmonte /media/DATA e verifique arquivos e pastas nesse caminho.

    

Answer 2

Eu uso regularmente 'ncdu' para isso, é pequeno o suficiente para continuar instalado.

sudo apt-get install ncdu

Apenas certifique-se de executá-lo como root ou via sudo:

sudo ncdu /

    

Answer 3

df -h *.* 

Pode ajudar.

Atravessa diretórios e soma os bytes usados.

    

Answer 4

Quando você quiser saber onde o espaço está sendo usado em um determinado sistema de arquivos, você pode usar este comando para encontrar os 20 maiores diretórios, o que pode ajudá-lo a localizar onde o maior espaço é usado,

du -m / |sort -n |tail -20

Mas o sistema de arquivos raiz é mais difícil, porque todos os sistemas de arquivos são montados na raiz. Mas o argumento -x (--one-file-system) reportará apenas o sistema de arquivos desejado,

du -m -x / |sort -n |tail -20