ext4: ¿Cómo dar cuenta del espacio del sistema de archivos?

Recientemente he formateado un disco de 1.5 TB con la intención de reemplazar ntfs con ext4.

Entonces noté que los archivos que guardé no caben en la nueva partición.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

Esa diferencia de bloques de 1K significa un deslumbrante espacio de 22 GiB menos utilizable.

Ya he ejecutado

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

con, como era de esperar, ningún efecto ya que eso no afecta a los bloques que simplemente no están allí.

Aún así, fdisk informa que la partición ext4 cubre todo el disco.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

Y así, por ejemplo, resize2fs informa que no hay "nada que hacer".

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      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 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

¿Qué está usando ese espacio perdido?

Veamos. El tamaño del dispositivo es 1,465,138,583½ kB = 1,500,301,909,504 B. El sistema de archivos consta de 366,284,288 bloques de 4096 B cada uno, que es 1,500,300,443,648 B. No sé para qué se usan los 1,465,856 B (1.4 MB) restantes (copias adicionales del superbloque ? Sé que hay unos pocos KB de espacio al principio para el gestor de arranque).

El sistema de archivos contiene 91,578,368 inodes de 256 bytes cada uno, que ocupa 23,444,062,208 B (aproximadamente 22 GB, pista, pista). Entonces hay 1,442,146,364 kB = 1,476,757,876,736 B para el contenido del archivo. Esto representa 23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944 B. El tamaño restante es 98,504,704 B = 24,029 bloques que está en el rango correcto para ser el tamaño del diario.

Como puede ver, todo se tiene en cuenta. (Ok, casi todo, pero estamos hablando de megabytes, no de gigabytes).

En primer lugar, la diferencia en el espacio disponible que está viendo no significa en absoluto que haya espacio "desperdiciado"; no se desperdicia porque es fundamental para que funcione el sistema de archivos. No debe comparar Ext4 y NTFS de esta manera sin un "pero" muy grande que especifique todas las diferencias estructurales y de diseño entre los sistemas de archivos, y también los detalles de cada implementación (por ejemplo, cómo cada controlador informa el espacio libre a la capa VFS).

Imagine la partición como un gran espacio donde puede colocar cualquier dato que tenga. Si solo tiene una pieza de datos con un tamaño igual a la partición, puede escribirla comenzando desde el principio de la partición y estar bien con ella. Pero tu no. En cambio, puede tener miles de archivos pequeños, y todos estos archivos agrupados de diferentes maneras, y cada archivo asociado con muchos otros pequeños datos (nombre, fecha / hora y permisos), etc. Debe organizar el gran espacio del partición para que pueda acceder a todos estos datos de manera rápida y eficiente. Además, debe preocuparse por cómo escribir nuevos datos y descartar datos viejos de manera eficiente. Necesitas estructuras de datos .

Y hay muchas estructuras de datos . Algunos de ellos son muy tontos, otros le permiten recuperar datos más rápidamente a expensas de escrituras más lentas, otros permiten escrituras más rápidas a expensas de lecturas, algunos aún pueden ser muy buenos tanto en lecturas como en escrituras, pero requieren pausas largas y sobrecarga inactiva mientras reorganiza los datos, etc.

Ciertamente quieres un sistema que:

1. Es muy rápido escribir información al respecto;
2. Es muy rápido recuperar información de él;
3. Es bueno para organizar y administrar la información almacenada en él;
4. Hace buen uso del espacio (partición) donde se almacena el sistema de archivos;
5. Es resistente a los problemas de hardware, por lo que aún puede recuperar la mayor parte o toda su información de fallas parciales del sistema;
6. Es resistente a los problemas de software, por lo que un error en una aplicación o una aplicación maliciosa instalada no destruirá sus datos de forma permanente;
7. Es resistente a los errores humanos, por lo que te perdona cuando accidentalmente ordena al sistema que elimine algo que no deberías (también conocido como la papelera / papelera de reciclaje).

Los sistemas de archivos de alto rendimiento permiten lecturas y escrituras muy rápidas a expensas de algo de espacio. Algunas de las estructuras de datos más rápidas utilizadas en los sistemas de archivos, como las tablas hash y los árboles B , son muy complejas y reservan más espacio del que realmente se utiliza para permitir accesos muy rápidos.

Ext4 tiene otras propiedades importantes. No hay un único punto de falla en el sistema de archivos. Hay muchas copias de datos críticos distribuidos a través de la partición, mientras que otros sistemas de archivos (no puedo decir para NTFS) pueden hacer que todos sus datos sean ilegibles si ocurre una falla en el lugar correcto. Además, Ext4 reserva mucho espacio para sus datos en la etapa de creación del sistema de archivos, mientras que NTFS crece con sus datos.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

Este mensaje indica que el disco usa particiones de estilo GPT, y esta fdiskherramienta solo comprende el estilo MBR heredado.

Para evitar reformateos accidentales si los discos con particiones GPT están conectados a sistemas más antiguos que no son compatibles con GPT, el esquema de particiones GPT incluye un "MBR protector": una tabla de particiones completamente falsa que básicamente dice "este disco está completamente en uso por un tipo de partición que usted no sé nada sobre "a ningún sistema operativo o herramienta que solo entienda la partición MBR.

Para obtener una visualización precisa de la tabla de particiones de su /dev/sdb, use:

parted /dev/sdb print