Eu tenho uma 115GB
partição no meu disco rígido (a saída cgdisk /dev/sda
está 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 /data
em 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 du
assim: 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 /data
está ocupando 51G
e então tenho os diretórios virtual-box
, temp
, manjaro-minikube
e .nuget
ocupando 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 51G
relatado for /data
, então espero que minha unidade tenha 65G
espaço quase vazio, mas por algum motivo, o /data
diretório pai está ocupando 51G
sozinho!
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ê /data
está tomando 51G
. Isso inclui todos os subdiretórios e arquivos dentro dele. Se você adicionar tamanhos relatados por du
subdiretórios (e considerar problemas de arredondamento), obterá cerca de 51G
. Se houvesse arquivos regulares diretamente em , eles também /data
contribuiriam para o valor relatado ./data
Portanto, du
não relata alto uso. É df
o que relata alto uso: 96G
está 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: du
percorre diretórios e adiciona tamanhos de objetos encontrados, df
consulta o sistema de arquivos sobre o conhecimento de seu próprio estado.
Essa grande discrepância pode ser porque:
du
não foi capaz de acessar (ou obter informações sobre) todos os objetos. Houve algumpermission denied
erro?- Há inconsistência no sistema de arquivos;
fsck.ext4
também conhecido comoe2fsck
pode 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
du
nã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 paradf
). 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_file
somente apóssome_daemon
parar 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 quedf
diz, mas nãodu
.
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 du
for /data
é a soma de todos os seus diretórios filhos (com alguns arredondamentos), acho que estava tentando justificar as discrepâncias entre df
e du
e pensei que deveria resumir du
a saída de for /data
e 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, 0
para o sexto campo, mas, como descobri, isso estava fazendo com que os inodes não fossem limpos, portanto causando a GRANDE diferença entre df
e 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í 28G
o uso em vez de 51G
), mas o bom é que ambos du
reportam df
o 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.