ext4: Comment tenir compte de l'espace du système de fichiers?

J'ai récemment formaté un disque de 1,5 To avec l'intention de remplacer ntfs par ext4.

Ensuite, j'ai remarqué que les fichiers que j'ai enregistrés ne tiennent pas sur la nouvelle partition.

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

Cette différence de 1K-blocs signifie un espace utilisable flagrant de 22 Gio.

J'ai déjà exécuté

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

avec, sans surprise, aucun effet car cela n'affecte pas les blocs qui ne sont tout simplement pas là.

Pourtant, fdisk signale que la partition ext4 couvre la totalité du disque.

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

Et ainsi, par exemple, resize2fs signale qu'il n'y a "rien à faire!"

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

À quoi sert cet espace manquant?

Voyons voir. La taille de l'appareil est de 1 465 138 583½ kB = 1 500 301 909 504 B. Le système de fichiers se compose de 366 284 288 blocs de 4096 B chacun, soit 1 500 300 443 648 B. Je ne sais pas à quoi servent les 1 465 856 B (1,4 Mo) restants (copies supplémentaires du superbloc). «Je sais qu'il y a quelques Ko d'espace au début pour le chargeur de démarrage.).

Le système de fichiers contient 91 578 368 inodes de 256 octets chacun, ce qui occupe 23 444 062 208 B (environ 22 Go, indice, indice). Ensuite, il y a 1 442 146 364 Ko = 1 476 757 876 736 B pour le contenu du fichier. Cela représente 23 444 062 208 B + 1 476 757 876 736 B = 1 500 201 938 944 B. La taille restante est de 98 504 704 B = 24 029 blocs, ce qui est dans la bonne plage pour être la taille du journal.

Comme vous pouvez le voir, tout est pris en compte. (D'accord, presque tout, mais nous parlons de mégaoctets, pas de gigaoctets.)

Tout d'abord, la différence d'espace disponible que vous voyez ne signifie pas du tout qu'il y a de l'espace «gaspillé»; il n'est pas gaspillé car il est d'une importance fondamentale pour le fonctionnement du système de fichiers. Vous ne devriez pas comparer Ext4 et NTFS de cette manière sans un très grand "mais" spécifiant toutes les différences de conception et de structure entre les systèmes de fichiers, ainsi que les spécificités de chaque implémentation (par exemple, comment chaque pilote signale l'espace libre à la couche VFS).

Imaginez la partition comme un immense espace où vous pouvez mettre toutes les données dont vous disposez. Si vous n'avez qu'une seule donnée avec une taille égale à la partition, vous pouvez simplement l'écrire à partir du début de la partition et être cool avec elle. Mais non. Au lieu de cela, vous pouvez avoir des milliers de petits fichiers, et tous ces fichiers regroupés de différentes manières, et chaque fichier associé à de nombreuses autres petites données (nom, date / heure et autorisations), etc. Vous devez organiser le grand espace du partitionner afin que vous puissiez atteindre toutes ces données rapidement et efficacement. En outre, vous devez vous soucier de la façon d'écrire de nouveaux éléments de données et de supprimer efficacement les anciens éléments de données. Vous avez besoin de structures de données .

Et il y a beaucoup de structures de données . Certains d'entre eux sont très stupides, d'autres vous permettent de récupérer des données plus rapidement au détriment d'écritures plus lentes, d'autres permettent des écritures plus rapidement au détriment des lectures, certains peuvent toujours être très bons à la fois en lecture et en écriture mais nécessitent de longues pauses et frais généraux inactifs pendant qu'il réorganise les données, etc.

Vous voulez certainement un système qui:

1. Est très rapide pour écrire des informations dessus;
2. Est très rapide pour en extraire des informations;
3. Sait organiser et gérer les informations qui y sont stockées;
4. Fait bon usage de l'espace (partition) où le système de fichiers est stocké;
5. Résiste aux problèmes matériels, de sorte que vous récupérez toujours la plupart ou la totalité de vos informations sur les défaillances partielles du système;
6. Résiste aux problèmes logiciels, de sorte qu'un bogue dans une application ou une application malveillante installée ne détruira pas vos données de façon permanente;
7. Résiste aux erreurs humaines, de sorte qu'il vous pardonne lorsque vous ordonnez accidentellement au système de supprimer quelque chose que vous ne devriez pas (alias la corbeille / la corbeille).

Les systèmes de fichiers hautes performances permettent des lectures et des écritures très rapides au détriment de l'espace. Certaines des structures de données les plus rapides utilisées dans les systèmes de fichiers, comme les tables de hachage et les arborescences B , sont très complexes, et elles réservent plus d'espace que ce qui est réellement utilisé afin de permettre des accès très rapides.

Ext4 possède d'autres propriétés importantes. Il n'y a pas de point de défaillance unique dans le système de fichiers. Il existe de nombreuses copies de données critiques réparties sur la partition, tandis que d'autres systèmes de fichiers (je ne peux pas dire pour NTFS) peuvent rendre toutes vos données illisibles si une panne se produit au bon endroit. De plus, Ext4 réserve beaucoup d'espace pour vos données dès la création du système de fichiers, tandis que NTFS grandit avec vos données.

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

Ce message indique que le disque utilise une partition de style TPG, et cet fdiskoutil ne comprend que l'héritage style MBR.

Pour éviter des reformatages accidentels si des disques partitionnés GPT sont connectés à des systèmes plus anciens non compatibles GPT, le schéma de partitionnement GPT comprend un "MBR protecteur": une table de partition complètement fausse qui indique essentiellement que "ce disque est complètement utilisé par un type de partition que vous Je ne sais rien "sur un système d'exploitation ou un outil qui ne comprend que le partitionnement MBR.

Pour obtenir un affichage précis de la table de partition de votre /dev/sdb, utilisez:

parted /dev/sdb print