Tamaño de partición ext4 / discrepancias de espacio libre

Al crear una partición de respaldo de 250GiB para mis datos, he notado muchas discrepancias entre el tamaño de partición informado y el espacio libre en Nautilus, gParted, df, tune2fs, etc.

Al principio pensé que era una confusión GiB / GB. No fue .

Entonces pensé que podrían ser los bloques reservados de ext4. No fue .

Estoy completamente perplejo. Aquí hay algunas imágenes. Aquí están los pasos:

Primero, NTFS. 524288000 sectores x 512 bytes / sector = 268435456000 bytes = 268.4 GB = 250 GiB.

ingrese la descripción de la imagen aquí

Nautilus dice " Capacidad total: 250.0 GB " (aunque en realidad es GiB, no GB). Aparte de ese pequeño etiquetado incorrecto, hasta ahora, todo bien

Ahora, la misma partición, formateada como ext4 con gparted:

ingrese la descripción de la imagen aquí

Los sectores Primero, Último y Total son iguales. Es la misma partición de 250GiB. El tamaño utilizado es 4.11GiB (¿quizás bloques reservados?)

ingrese la descripción de la imagen aquí

No Parece que los bloques reservados son 12.7 GiB (~ 5%. ¡Ay! ). Pero ... ¿por qué la capacidad total ahora es de solo 246.1 GiB? . Esa diferencia (más o menos) coincide con el 4.11 GiB informado por gparted. Pero ... si no es de bloques reservados, ¿qué es? ¿Y por qué gparted no informó que 12.7GiB de espacio usado?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfcoincide con Nautilus en el espacio libre reportado. Pero ... ¿solo 188M usados? ¿No debería ser ~ 12GB? Y la capacidad total todavía está mal. Entonces corrí tune2fsa buscar algunas pistas. (se omite la salida irrelevante)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 bloques totales * 4096 bytes / bloque = 268435456000 bytes = 268.4 GB = 250 GiB. Coincide con gparted.

3276800 bloques reservados = 13421772800 bytes = 13.4 GB = 12.5 GiB. (De nuevo, más o menos) coincide con Nautilus.

64459851 bloques libres = 264027549696 bytes = 264.0 GB = 245.9 GiB. ¿Por qué? ¿No debería ser 250-12.5 = 237.5 (o 250- (12.5 + 4.11) = ~ 233)?

Eliminar bloques reservados:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

Como se esperaba, el mismo recuento de bloques, 0 bloques reservados, pero ... ¿los mismos bloques libres ? ¿Acabo de liberar 12.5 GiB?

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

ingrese la descripción de la imagen aquí

Parece que lo hice El espacio disponible aumentó de 233 a 245.9 GiB. ¡a gparted no le importó en absoluto, mostrando exactamente la misma información! (inútil publicar una captura de pantalla idéntica)

¡Qué gran desastre!

Traté de documentarlo lo mejor que pude ... Entonces, ¿alguien puede darme alguna pista de lo que está pasando aquí?

¿Cuáles son los misteriosos 4.11 GiB que faltan en NTFS -> formato ext4?
¿Por qué hay tantas discrepancias entre gparted, Nautilus, tune2fs, df?
¿Qué hay de malo en mis matemáticas? (las preguntas en negrita dispersaron esta publicación)

Cualquier ayuda es apreciada. Si bien no puedo entender lo que está sucediendo, estoy considerando seriamente renunciar a ext4 a favor de NTFS para todo menos mi / partición.

¡Gracias!

— MestreLion
fuente

askubuntu.com/questions/24371/…

— Uri Herrera

askubuntu.com/questions/22102/meaning-of-i-in-mib/22112#22112

— Uri Herrera

@Uri Herrera: ¿realmente leíste mi pregunta, o al menos las primeras líneas? Este no es un problema GiB / GB. La partición es 268.4GB = 250.0GiB, no 246.1

— MestreLion

Otra respuesta que puede consultar: askubuntu.com/questions/5335/…

— enzotib

Consulte también ext4: ¿Cómo dar cuenta del espacio del sistema de archivos?

— Gilles 'SO- deja de ser malvado'

Respuestas:

Hay algunas cosas pasando aquí. gparted informa el espacio real utilizado / libre. El núcleo reduce el recuento disponible por el espacio reservado. Después de eliminar el espacio reservado, el conteo gratuito no cambió porque los bloques reservados ya estaban libres; es solo que los usuarios no root no pueden invadir ese espacio para evitar que causen problemas al llenar el disco. Los números de los gnomos son un poco escamosos debido a un error . En lugar de informar el espacio utilizado que informa el núcleo (y muestra df), lo calcula restando el espacio libre del total. Esto hace que muestre el espacio reservado como se usa.

Los 4 GB que faltan realmente se utilizan son los gastos generales de fs para ext4. NTFS solo asigna inicialmente una pequeña cantidad de espacio para la MFT y la aumenta según sea necesario. Sin embargo, la serie ext de sistemas de archivos asigna espacio para la tabla de inodo (equivalente aproximado de la MFT) en el momento del formato y no puede crecer. El espacio que falta en el espacio total informado es la tabla de inodo. El bit restante del espacio utilizado proviene del diario (generalmente 128 mb) y cambia el tamaño de los inodos.

— psusi
fuente

¡Gracias, +1 por resolver algunos de los misterios! Pero, si los ~ 4 GB son sobrecarga del sistema de archivos, ¿por qué algo (3.9 GB) se deduce del espacio total, mientras que 188 MB se muestran como realmente utilizados? ¿Cuál (o ambos) es la sobrecarga? ¿Y por qué se maneja de manera diferente? Además, dfincluso con sudo, muestra la capacidad total (247 GB) y el espacio utilizado (188 MB) como Nautilus. Entonces, si es un error, no es solo un gnomo.

— MestreLion

Pensé que los 188 MB eran los gastos generales (en comparación con los 72 MB de NTFS). Pero, si la sobrecarga de NTFS crecerá con el tiempo, ¿eso significa que Nautilus informará más tarde que su capacidad total se está reduciendo ?

— MestreLion

Corrección: df siempre muestra el espacio disponible, sin importar quién lo ejecute. Para ver el espacio libre (== espacio disponible + espacio reservado), use stat -f /media/BACKUP.

— Marius Gedminas

Respuesta editada para aclarar. Y creo que NTFS solo informará más espacio utilizado, no reducirá el total a medida que crece el MFT. @ Mario, esto tampoco es correcto. statfs () y, por lo tanto, df y stat -f muestran el espacio disponible sin contar los bloques reservados. Podría haber jurado que también se ajustó a la cuota y varió su respuesta en función del usuario que llama, pero tienes razón en eso; no cuenta la cuota y no le importa cómo la llame el usuario.

— psusi

@psusi: ¿entonces tengo ~ 3.9GiB de tabla de inodo y ~ 188MB de diario + algo? ¿Y Nautilus resta la tabla de inodo del Tamaño total, mientras informa el diario como espacio utilizado? ¿Y gparted los informa como un solo 4.11GiB de espacio usado? ¿Es eso correcto? Si es así, simplemente desearía que Nautilus manejara ambos gastos generales de la misma manera ... ambos restados del total o ambos contados como "espacio usado" (preferiblemente).

— MestreLion

En primer lugar, los bloques reservados no son bloques utilizados para la gestión interna del sistema de archivos.

Los bloques reservados están simplemente reservados para rootasegurar que los servicios que usan archivos en esa partición no puedan ser descartados por un usuario que no sea administrador llenando todo el espacio.

Incluso sin bloques reservados ( -m 0) siempre hay una parte del espacio utilizado para la administración interna del sistema de archivos, no puedo decir cuánto, no tengo un conocimiento tan profundo.

Además, Gparted se ejecuta como root, por lo que ve los bloques reservados como gratuitos. Nautilus , ejecutado como usuario, los ve como no gratuitos.

Ok, la respuesta de @psusi es muy clara, no tengo nada que agregar.

— enzotib
fuente

Humm, muy informativo, +1. Al menos esto resuelve algunos de los problemas que he encontrado. Al ver los bloques reservados como un "límite máximo" para no root en lugar de "bloques usados", las lecturas de gparted, df y tune2fs están de acuerdo (y tienen sentido). Pero aún quedan algunas preguntas, especialmente los 4 GB de espacio utilizado / capacidad total.

— MestreLion

Además, he leído en alguna parte (uno de esos viejos "¿por qué no necesita desfragmentar su partición de Linux cada mes", tal vez?) Que reservar un 5% de espacio para la raíz da un respiro a los algoritmos de asignación extN y, por lo tanto, evita fragmentación.

— Marius Gedminas

Intente reducir el tamaño de la partición en unos pocos megabytes con gparted, luego aumente nuevamente a su tamaño original. Esto puede hacer que otras aplicaciones lean los tamaños correctamente. ¡Recientemente corregí un error de 50 Gb de esta manera!

— jim abedul
fuente