Tengo una 115GBpartición en mi disco duro (el resultado cgdisk /dev/sdaestá a continuación):
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
Y he montado esa partición /dataen mi /etc/fstab:
UUID=<drive-uuid> /data ext4 defaults 0 0
Cuando lo hago df -h /data, tengo el siguiente resultado:
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 113G 96G 11G 90% /data
Y cuando uso duasí:, du /data -h --max-depth=1 | sort -hrveo esto:
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
lo cual, si no me equivoco, muestra que /dataestá ocupando 51Gy luego tengo los directorios virtual-box, temp, manjaro-minikubey .nugetocupando espacio (los otros no ocupan espacio significativo)
Si hago un listado largo de mi directorio ( 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
No veo ningún archivo o algo que contribuya a lo 51Ginformado /data, por lo que espero que mi disco tenga 65Gespacio casi vacío, pero por alguna razón, ¡el /datadirectorio principal se está ocupando 51Gsolo!
Intenté buscar en Internet, pero no encontré nada. ¿Alguien puede decirme qué está pasando?
ACTUALIZAR
Como se sugiere en las respuestas, ejecuté lsof /data | grep deleted(como root), pero no obtuve ningún resultado, aunque veo una advertencia, que no estoy seguro de que sea relevante:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
Respuesta1
Estás /datatomando 51G. Esto incluye todos los subdirectorios y archivos que contiene. Si agrega los tamaños informados por dupara los subdirectorios (y considera los problemas de redondeo), obtendrá aproximadamente 51G. Si hubiera archivos normales directamente en , también /datacontribuirían al valor informado ./data
Por lo tanto, duno informa un uso elevado. Es dflo que informa un uso elevado: 96Gestá en uso en el sistema de archivos.
Como /dataes un punto de montaje, es de esperar que los dos valores sean iguales. Pero las dos herramientas funcionan de manera diferente: durecorre directorios y agrega tamaños de objetos encontrados, dfconsulta al sistema de archivos sobre su conocimiento de su propio estado.
Una discrepancia tan grande puede deberse a:
duno pudo acceder (u obtener información sobre) todos los objetos. ¿Hubo algúnpermission deniederror?- Hay inconsistencia en el sistema de archivos;
fsck.ext4aliase2fsckpuede ayudar. (más probable) Hay al menos un archivo que se eliminó (se eliminaron todas las entradas del directorio que apuntan al inodo respectivo, el archivo no aparece en ninguna lista de directorios, por lo que
duno puedo saberlo) pero todavía está en uso por algún proceso (por lo que el sistema de archivos guarda los datos y los tiene en cuenta al informar adf). Veresta respuesta,esta pregunta.El siguiente comando debería encontrar dichos archivos y procesos usándolos:
lsof /data | grep deletedSalida de ejemplo:
some_daemon … … … … … … … /data/temp/huge_file (deleted)Esto significa que el sistema de archivos realmente eliminará el archivo
huge_filesólo después de quesome_daemondeje de usarlo. Tenga en cuenta que, en general, el proceso aún puede agregarse al archivo o truncarlo, por lo que el archivo puede crecer o reducirse. Esto afectará lo quedfdice, pero nodu.
Respuesta2
Resulta que hubo algunos problemas aquí (gracias @Kamil por ayudar a encontrarlos):
Aunque esta fue mi intuición inicial de que la cantidad reportada por dufor /dataes la suma de todos sus directorios secundarios (con algo de redondeo), supongo que estaba tratando de justificar las discrepancias entre dfy duy pensé que debería resumir duel resultado de for /datay all sus directorios secundarios para obtener el mismo resultado que df.
El otro problema, que es el principal que causa las discrepancias, se debió a cómo había configurado mi /etc/fstab:
UUID=<uuid> /data ext4 defaults 0 0
^
ISSUE
Cuando creé mi archivo /etc/fstab, pensé que no necesitaría prolongar mi inicio habilitando las comprobaciones del sistema de archivos ( fsck) en mi montaje, por lo tanto, 0para el sexto campo, pero resultó que esto estaba causando que los inodos no se limpiaran, por lo tanto causando la GRAN diferencia entre dfy du.
Entonces, mirando man 5 fstab, podemos ver que, para habilitar las comprobaciones, el sistema de archivos raíz debe tener valor 1y otros sistemas de archivos deben tener valor 2, así que cambié la línea para que sea:
UUID=<uuid> /data ext4 defaults 0 2
Y después de reiniciar, se informaron muchos problemas fsck, elegí solucionarlos y ahora aparece el resultado 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
Y salida de df /data -h:
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 113G 28G 80G 26% /data
Vale la pena señalar que, en comparación con mi pregunta original, eliminé algunos archivos (de ahí 28Gel uso en lugar de 51G), pero lo bueno es que ambos duinforman dfel mismo valor :)
Respuesta3
Su comando es ordenar los resultados de mayor a menor. El valor más alto es eltotalespacio utilizado por /data, no el espacio que ha utilizado por sí mismo.