¿Hay alguna manera de hacer que los sistemas de archivos ext usen menos espacio para sí mismos en Linux?

Tengo un montón de discos duros externos e internos que uso en un sistema Linux. Solo tengo sistemas Linux, por lo que usar un sistema de archivos Linux solo tendría sentido, ¿verdad? Sin embargo, actualmente estoy usando NTFS en todas partes, porque me da el espacio más utilizable de los discos duros.

Sin embargo, me gustaría cambiar a los sistemas de archivos Linux ahora, principalmente debido a los permisos y la compatibilidad (por ejemplo, no puedo hacer que mi partición NTFS cifrada con LUKS cambie de tamaño en Linux, sigue diciéndome que haga chkdsk en Windows).

Sin embargo, cuando formateé esos discos duros, probé un montón de sistemas de archivos diferentes y cada sistema de archivos de Linux, incluso ext2 que, hasta donde sé, no tiene registro en diario, utilizó mucho espacio para sí mismo. No recuerdo los valores exactos, pero fue más de 100 GB que NTFS me consiguió más en un disco duro de 2 TB, que es mucho.

Entonces mi pregunta es: ¿hay alguna manera de hacer que los sistemas de archivos ext usen menos espacio para ellos? ¿O hay otro sistema de archivos (probé ext2, ext3, ext4, NTFS y vfat, ninguno de ellos se acercó al espacio utilizable que NTFS me ofreció) con soporte perfecto para Linux y excelente espacio utilizable?

Me encantaría saber cómo y por qué los sistemas de archivos (especialmente ext2 que no tiene registro diario) usan mucho más espacio que NTFS y no sé dónde más preguntar. En su mayoría, preferiría una forma de usar ext4 sin diario y cualquier otra cosa que use tanto espacio, si eso es posible.

— papel picado
fuente

¿Has visto este hilo ?

— JakeGould

Sí, y explicó qué utiliza el espacio extra, pero la diferencia entre NTFS y ext es MUCHO mayor que entre reiserfs y ext, y me pregunto si hay alguna forma de hacerlo más pequeño. Por ejemplo, en un disco duro de 1 TB, puedo usar 989 GB con NTFS. ext4 me daría alrededor de 909 GB.

— confeti

Lo suficientemente justo. Pregunta decente y la respuesta también es esclarecedora.

— JakeGould

¿Cómo se mide realmente el espacio disponible? Esto es importante porque dependiendo de los valores que mire, puede ver o no el efecto de la reserva del 5%, por ejemplo, como se indica en la pregunta vinculada

— eMBee

Tenga en cuenta que escribir en un diario en sistemas de archivos como ext3 y ext4 es algo bueno. Es bastante fácil perder energía en un disco externo o desconectarlo por accidente si es un USB. Cuando eso sucede, a menudo no es gran cosa porque se cura a sí mismo usando el diario cuando se inicia una copia de seguridad. Sin esa red de seguridad, las cosas serían mucho peores. No es solo un caso de más, es mejor.

— Joe

Respuestas:

Por defecto, ext2 y sus sucesores reservan el 5% del sistema de archivos para uso del usuario root. Esto reduce la fragmentación y hace que sea menos probable que el administrador o cualquier demonio propiedad de root se quede sin espacio para trabajar.

Estos bloques reservados evitan que los programas que no se ejecutan como root llenen su disco. Si estas consideraciones justifican la pérdida de capacidad depende de para qué se utilice el sistema de archivos.

La cantidad del 5% se estableció en la década de 1980 cuando los discos eran mucho más pequeños, pero simplemente se dejaron como están. Hoy en día, el 1% es probablemente suficiente para la estabilidad del sistema.

La reserva se puede cambiar usando la -mopción del tune2fscomando:

tune2fs -m 0 /dev/sda1

Esto establecerá el porcentaje de bloques reservados en 0% (0 bloques).

Para obtener el valor actual (entre otros), use el comando:

tune2fs -l <device>

— harrymc
fuente

Esto explicaría perfectamente la inmensa diferencia en el espacio utilizable (ya que el 5% de 2TB son 100GB). Los discos no se usarán para nada relacionado con la raíz o el archivo del sistema, por lo que creo que sería seguro desactivar esto. Sin embargo, tengo una pregunta: ¿cómo saben los programas propiedad de root que hay más espacio libre que los programas no root? Ejecutar dfcomo no root frente a root no muestra ninguna diferencia.

— confeti

@confetti: Porque el VFS no rechaza sus intentos de escribir en el disco con un error (hasta que el volumen esté realmente lleno, por supuesto).

— Ignacio Vazquez-Abrams

tune2fs -l <device>debería dar este valor entre otros. La cantidad del 5% se estableció en la década de 1980 cuando los discos eran mucho más pequeños, pero simplemente se dejaron como están. Hoy en día, el 1% es probablemente suficiente para la estabilidad del sistema.

— harrymc

XFS reserva el más pequeño de 5% o 8192 bloques (32 MiB), por lo que la cantidad reservada es generalmente pequeña en comparación con el tamaño del sistema de archivos.

— Michael Hampton

Muchas gracias a todos por las explicaciones. Esto me ayudó a entender mucho. Mi disco solía llenarse completamente hasta su último byte antes, pero mi sistema no falló por completo, ahora entiendo por qué.

— confeti el

Si los datos que desea almacenar son comprimibles, btrfs montados con compress=zstd(o compress-force=zstd) probablemente usarían significativamente menos espacio en disco que ext *

esto hará que btrfs comprima sus datos de forma transparente antes de escribirlos en el disco y los descomprima de manera transparente cuando los lea de nuevo. Además, ext4 asigna previamente todos los inodos en la creación del sistema de archivos, btrfs los crea según sea necesario, supongo que eso también puede ahorrar algo de espacio.

— Hanshenrik
fuente

¿Te importaría agregar más información a esta respuesta? (Cómo funciona, qué hace, tal vez una referencia, ...)

— confeti

@confetti como este? patchwork.kernel.org/patch/9817875

— hanshenrik

Realmente me gusta esta idea, pero sería bueno tener más información sobre cómo afectaría la velocidad y el rendimiento.

— confeti el

@confetti, dado que está utilizando un disco duro, probablemente mejorará el rendimiento. Las CPU son mucho más rápidas que los discos duros que la parte lenta del acceso al disco es poner los datos dentro y fuera del disco; el tiempo dedicado a comprimir o descomprimir no se notará.

— Mark

Por otro lado, la mayoría de los tipos de archivos grandes en la actualidad (por ejemplo, imágenes, audio, video, incluso los formatos de documentos de texto más ricos) tienden a estar ya comprimidos y, en general, no se benefician de una compresión adicional. Al menos no del tipo simple de propósito general realizado a nivel de sistema de archivos.

— Ilmari Karonen

Otro punto del que aún no se ha hablado es la cantidad de inodos que reserva en su sistema de archivos.

Por defecto, mkfs crea una serie de inodos que deberían permitir colocar una gran cantidad de archivos muy pequeños en su sistema de archivos. Si sabe que los archivos serán muy grandes y solo colocará una pequeña cantidad de archivos en el FS, puede reducir la cantidad de inodos.

¡Cuídate! Este número (es decir, la relación entre el espacio y el número de inodes) solo se puede establecer en el momento de creación del sistema de archivos. Incluso cuando se extiende el FS, la relación sigue siendo la misma.

— glglgl
fuente

Alternativamente, si sabe que va a almacenar muchos archivos realmente pequeños, puede aumentar el número de inodos y disminuir el tamaño del bloque para no desperdiciar tanto espacio. (Cada archivo debe consumir un mínimo de un bloque, incluso si es de 1 byte. Use ls -ls para comparar el tamaño frente a lo que se usa en el disco).

— Perkins

@Perkins Tienes razón, pero creo que esto solo es válido para archivos MUY pequeños: el tamaño de bloque predeterminado es 4 kB (IIRC), el mínimo es 1 kiB. Así que no hay mucho que ganar, excepto que su disco está realmente lleno de esos archivos. Pero sin embargo, podría sumergirme en esto mañana.

— glglgl

o alternativamente use btrfs, que crea inodes según sea necesario. Mientras que los inodes de ext4 se asignan en el momento de la creación del sistema de archivos y no se pueden redimensionar después de la creación, con un límite rígido de 4 mil millones, los inodos de btrfs se crean dinámicamente según sea necesario, y el límite rígido es 2 ^ 64, alrededor de 18.4 quintillones, que es alrededor de 4.6 mil millones veces mayor que el límite duro de una ext4

— máxima

Me recuerda configurar un carrete de Usenet. ext4 almacenará pequeño (el límite es de 60-160 bytes dependiendo de muchas cosas) dentro del inodo mismo.

— Sr.Spuratic

@hanshenrik Tenga en cuenta que tiene la misma limitación de tamaño de bloque en btrfs (con un par de formas adicionales para solucionarlo), por lo que aún necesita saber qué tipo de archivos (grandes o pequeños o ambos) va a almacenar y ajuste su sistema de archivos en consecuencia si desea exprimir la cantidad máxima de almacenamiento. Sin embargo, la disponibilidad de compresión automática ayuda bastante si está almacenando datos esponjosos.

— Perkins