.png)
Estoy un poco desconcertado por la forma en que los informes ext4 utilizan el espacio. En una nueva instalación (de prueba) de Debian wheezy, utilicé constantemente alrededor de 1 GB de espacio adicional con un SSD de 60 GB, en comparación con du. Luego inicié en red esa computadora y monté el SSD. El sistema operativo arrancado en red (Debian squeeze) muestra solo 180 MB de espacio adicional utilizado en el SSD. El diario tiene 128 MB, por lo que ya no hay mucho más que eso.
¿Cuál es el espacio adicional utilizado que informa df, cuando no es espacio reservado para archivos raíz o eliminados? El uso de Google provoca principalmente las causas habituales, que he descartado. ¿Y por qué esa cantidad difiere en el mismo sistema de archivos cuando se monta en diferentes sistemas operativos? Probé esto reinstalándolo, y el uso adicional fue nuevamente de ~1 GB en la instalación con sibilancias y 180 MB cuando inicié en red y monté ese SSD.
En XFS y btrfs, el uso adicional reportado parece insignificante. Me doy cuenta de que el sistema de archivos necesita algo de sobrecarga, pero es inconveniente cuando esa sobrecarga se mezcla con el uso real.
A continuación se muestran algunos resultados detallados.
df
$ df -m on wheezy
Filesystem 1M-blocks Used Available Use% Mounted on
rootfs 57132 1567 52703 3% /
udev 7899 0 7899 0% /dev
tmpfs 1581 1 1581 1% /run
/dev/mapper/ssd-kvmhost 57132 1567 52703 3% /
tmpfs 5 0 5 0% /run/lock
tmpfs 3162 0 3162 0% /tmp
tmpfs 3162 0 3162 0% /run/shm
du
$ du -sm /
592 /
tune2fsmuestra que el recuento de inodos es 3670016 y el tamaño 256, lo que de hecho explica casi todo el espacio utilizado. Simplemente no entiendo por qué esto no se resta del Tamaño, ya que los inodos están reservados estáticamente. Contarlo como espacio y luego contarlo siempre como usado no tiene mucho sentido.
Aquí está el resultado para el mismo sistema de archivos, desde Debian squeeze arrancado en red:
aufs 7905 46 7859 1% /
tmpfs 7905 0 7905 0% /lib/init/rw
udev 7900 1 7900 1% /dev
tmpfs 7905 1 7905 1% /dev/shm
172.17.172.127:/storage/private/tftp/debian-live-6.0.3-amd64-lxde-desktop
24737 17448 7289 71% /live/image
tmpfs 7905 46 7859 1% /live/cow
tmpfs 7905 0 7905 0% /live
tmpfs 7905 1 7905 1% /tmp
/dev/mapper/ssd-kvmhost
56337 772 52703 2% /mnt
Y solo para confirmación, du -sm / en el sistema operativo iniciado en la red:
592 /
¿Quizás el kernel más antiguo no cuenta sabiamente el espacio de inodo reservado estáticamente como utilizable y, por lo tanto, no tiene que mostrarlo como usado? La diferencia es de 795MB tanto en Tamaño como en Usado, casi todo el espacio necesario para los inodos. ¿Cuáles son los 180 MB entonces? Si eso también es estático, ¿no sería óptimo restarlo también del Tamaño? Entonces dfpodría mostrar un uso real, como parecen hacer otros sistemas de archivos.
A mi modo de ver, si mi sistema de archivos necesita una cantidad estática de sobrecarga, entonces simplemente proporciona menos espacio utilizable que otros sistemas de archivos para la misma cantidad de espacio absoluto. ¿No debería reflejar eso y también mostrar cuánto delespacio utilizable¿He usado?
Respuesta1
ext[234] de forma predeterminada reserva 8192 inodos por grupo de bloques de 128 mb, lo que requiere 2 mb, por grupo, lo que equivale a cerca de 1 gb para un sistema de archivos de 60 gb. No debería haber ninguna diferencia cuando monte la unidad en otro sistema. Parece que pueden haber cambiado la forma en que los informes del kernel utilizan el espacio entre sibilancias y compresión, aunque todavía no he encontrado una confirmación que indique que esto se hizo a propósito.
Respuesta2
Su pregunta sería más fácil de responder si proporcionara el resultado de df y du.
Pero suena mucho a df dice que tengo 20G más de espacio en disco utilizado que du. ¿Por qué?
Básicamente, su sistema de archivos utiliza parte del disco para sus propios metadatos, es decir, no los archivos en sí, sino para realizar un seguimiento de los archivos, sus nombres, sus permisos, su ubicación en el disco, etc.
Como dice la respuesta que vinculé anteriormente, ejecutar tune2fs -l <device name>le mostrará más información. En particular, inode countx inode sizedebería estar cerca de la diferencia entre dfy du.
Nuevamente, según la respuesta anterior, la partición raíz de mi sistema utiliza aproximadamente el 1,77% del disco para inodos. 60 GB * 0,0177 ~= 1 GB.
Sospecho que la cifra de 180 MB es incorrecta, pero no puedo estar seguro sin más detalles, por ejemplo, la salida de mountsu sistema iniciado en red. Por ejemplo, tal vez se deba a laminixdf/bsddfopción de montaje.