A pasta está vazia, mas du relata alto uso

A pasta está vazia, mas du relata alto uso

Eu tenho uma 115GBpartição no meu disco rígido (a saída cgdisk /dev/sdaestá abaixo):

Part. #     Size        Partition Type            Partition Name
----------------------------------------------------------------
            1007.0 KiB  free space
   1        499.0 MiB   Windows RE                Basi
   2        100.0 MiB   EFI System                EFI 
   3        16.0 MiB    Microsoft reserved        Micr
   5        43.9 GiB    Linux filesystem          ubuntu-root
   6        43.9 GiB    Linux filesystem          ubuntu-home
   4        114.9 GiB   Linux filesystem          data         <--- this partition
   7        29.5 GiB    Linux filesystem

E eu montei essa partição /dataem meu /etc/fstab:

UUID=<drive-uuid>  /data  ext4  defaults  0  0

Quando faço isso df -h /data, tenho a seguinte saída:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda4       113G   96G   11G  90% /data

E quando eu uso duassim: du /data -h --max-depth=1 | sort -hr, vejo isso:

51G    /data
40G    /data/virtual-box
4.4G   /data/temp
4.1G   /data/manjaro-minikube
1.9G   /data/.nuget
764M   /data/OneDrive
62M    /data/manjaro-lxd
40K    /data/.minikube
16K    /data/lost+found

que, se não me engano, está mostrando que /dataestá ocupando 51Ge então tenho os diretórios virtual-box, temp, manjaro-minikubee .nugetocupando espaço (os outros não ocupam espaço significativo)

Se eu fizer uma listagem longa do meu diretório ( ls -alh /data):

total 68K
drwxr-xr-x  10 farzad farzad 4.0K Aug 13 21:47 .
drwxr-xr-x  19 root   root   4.0K Jul 13 10:32 ..
drwx------   2 farzad farzad  16K Mar 22 18:22 lost+found
drwx--x--x  15 root   root   4.0K Aug 20 17:47 manjaro-lxd
drwxr-xr-x   3 farzad farzad 4.0K Jul  3 18:16 manjaro-minikube
drwxrwxr-x   9 farzad farzad 4.0K Jul 30 17:38 .minikube
drwxr-xr-x 202 farzad farzad  16K Aug 17 10:00 .nuget
drwxr-xr-x   3 farzad farzad 4.0K Aug 13 21:47 OneDrive
drwxrwxr-x  16 farzad farzad 4.0K Jun  3 21:45 temp
drwxr-xr-x   6 farzad farzad 4.0K Aug 20 20:21 virtual-box

Não vejo nenhum arquivo ou algo contribuindo para o 51Grelatado for /data, então espero que minha unidade tenha 65Gespaço quase vazio, mas por algum motivo, o /datadiretório pai está ocupando 51Gsozinho!

Tentei pesquisar na Internet, mas não encontrei nada. Alguém pode me informar o que está acontecendo?


ATUALIZAR

Conforme sugerido nas respostas, executei lsof /data | grep deleted(como root), mas não tenho nenhum resultado, embora veja um aviso, que não tenho certeza se é relevante:

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

Responder1

Você /dataestá tomando 51G. Isso inclui todos os subdiretórios e arquivos dentro dele. Se você adicionar tamanhos relatados por dusubdiretórios (e considerar problemas de arredondamento), obterá cerca de 51G. Se houvesse arquivos regulares diretamente em , eles também /datacontribuiriam para o valor relatado ./data

Portanto, dunão relata alto uso. É dfo que relata alto uso: 96Gestá em uso no sistema de arquivos.

Como /dataé um ponto de montagem, você pode esperar que os dois valores sejam iguais. Mas as duas ferramentas funcionam de maneira diferente: dupercorre diretórios e adiciona tamanhos de objetos encontrados, dfconsulta o sistema de arquivos sobre o conhecimento de seu próprio estado.

Essa grande discrepância pode ser porque:

  • dunão foi capaz de acessar (ou obter informações sobre) todos os objetos. Houve algum permission deniederro?
  • Há inconsistência no sistema de arquivos; fsck.ext4também conhecido como e2fsckpode ajudar.
  • (provavelmente) Há pelo menos um arquivo que foi excluído (todas as entradas de diretório que apontam para o respectivo inode foram removidas, o arquivo não aparece em nenhuma listagem de diretório, portanto dunão posso saber sobre ele), mas ainda está em uso por algum processo (portanto, o sistema de arquivos mantém os dados e os leva em consideração ao reportar para df). Veresta resposta,essa questão.

    O comando a seguir deve encontrar esses arquivos e processos usando-os:

    lsof /data | grep deleted
    

    Exemplo de saída:

    some_daemon  …  …  …  …  …  …  …  /data/temp/huge_file (deleted)
    

    Isso significa que o sistema de arquivos realmente será excluído huge_filesomente após some_daemonparar de usá-lo. Observe que, em geral, o processo ainda pode ser anexado ao arquivo ou truncá-lo, portanto, o arquivo pode aumentar ou diminuir. Isso afetará o que dfdiz, mas não du.

Responder2

Acontece que houve alguns problemas aqui (obrigado @Kamil por ajudar a encontrá-los):

Embora esta tenha sido minha intuição inicial de que o valor relatado por dufor /dataé a soma de todos os seus diretórios filhos (com alguns arredondamentos), acho que estava tentando justificar as discrepâncias entre dfe due pensei que deveria resumir dua saída de for /datae todos seus diretórios filhos para obter o mesmo resultado que df.

O outro problema, que é o principal que causa as discrepâncias, foi a forma como configurei meu /etc/fstab:

UUID=<uuid>  /data  ext4  defaults  0  0
                                       ^
                                     ISSUE

Quando criei meu /etc/fstab, pensei que não precisaria prolongar minha inicialização habilitando verificações do sistema de arquivos ( fsck) em minha montagem, portanto, 0para o sexto campo, mas, como descobri, isso estava fazendo com que os inodes não fossem limpos, portanto causando a GRANDE diferença entre dfe du.

Então, olhando para man 5 fstab, podemos ver que, para habilitar verificações, o sistema de arquivos raiz deveria ter value 1, e outros sistemas de arquivos deveriam ter value 2, então mudei a linha para:

UUID=<uuid>  /data  ext4  defaults  0  2

E após a reinicialização, muitos problemas foram relatados por fsck, optei por corrigi-los e agora a saída de du /data -h --max-depth=1 | sort -hr:

28G    /data
16G    /data/virtual-box
4.5G   /data/temp
4.1G   /data/manjaro-minikube
1.9G   /data/.nuget
824M   /data/OneDrive
64M    /data/manjaro-lxd
40K    /data/.minikube
16K    /data/lost+found

E saída de df /data -h:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda4       113G   28G   80G  26% /data

É importante notar que, em comparação com minha pergunta original, removi alguns arquivos (daí 28Go uso em vez de 51G), mas o bom é que ambos dureportam dfo mesmo valor :)

Responder3

Seu comando está classificando os resultados do maior para o menor. O valor mais alto é ototalespaço usado por /data, não o espaço que ele usou sozinho.

informação relacionada