Différences de taille de partition / d'espace libre ext4
Lors de la création d'une partition de sauvegarde 250GiB pour mes données, j'ai constaté de nombreux écarts entre la taille de partition signalée et l'espace disponible dans Nautilus, gParted, df, tune2fs, etc.
Au début, je pensais que c’était une confusion GiB/GB. Ce n'était pas .
Ensuite, j'ai pensé que cela pourrait être les blocs réservés d'ext4. Ce n'était pas .
Je suis complètement perplexe. Voici quelques images. Voici les étapes:
- Premièrement, NTFS. 524288000 secteurs x 512 octets/secteur = 268435456000 octets = 268,4 Go = 250 Go.
Nautilus dit "Capacité totale: 250,0 Go" (même s’il s’agit de GiB et non de Go). En dehors de cette erreur d'étiquetage mineur, jusqu'ici, tout va bien
- Maintenant, même partition , formatée en ext4 avec gparted:
Les secteurs Premier, Dernier et Total sont les mêmes. C'est IS la même partition de 250 Go. La taille utilisée est 4.11GiB (des blocs réservés peut-être?)
Nan. On dirait que les blocs réservés sont 12.7 GiB (~ 5%. ouch! ). Mais ... pourquoi la capacité totale n’est plus que de 246,1 GiB ???. Cette différence (en quelque sorte) correspond au 4.11 GiB rapporté par gparted. Mais ... si ce n'est pas de blocs réservés, qu'est-ce que c'est? Et pourquoi gparted n'a-t-il pas signalé 12,7 Go d'espace utilisé?
$ df -h /dev/sda5
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 247G 188M 234G 1% /media/BACKUP
df correspond à Nautilus dans l'espace disponible signalé. Mais .. seulement 188M utilisés? Ne devrait-il pas être ~ 12 Go? Et la capacité totale est toujours mauvaise. J'ai donc lancé tune2fs pour trouver des indices. (la sortie non pertinente est omise)
$ 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 nombre total de blocs * 4096 octets/bloc = 268435456000 octets = 268,4 Go = 250 Go. Cela correspond à gparted.
3276800 blocs réservés = 13421772800 octets = 13,4 Go = 12,5 Gio. Cela (encore une fois) correspond à Nautilus.
64459851 blocs libres = 264027549696 octets = 264.0 Go = 245.9 GiB. Pourquoi? Ne devrait-il pas être 250-12.5 = 237.5 (ou 250- (12.5 + 4.11 ~ 233)?) ==
Supprimer les blocs réservés:
$ 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
Comme prévu, même nombre de blocs, 0 bloc réservé, mais ... mêmes blocs libres ? Je ne viens pas de libérer 12,5 GiB?
$ df -h /dev/sda5
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 247G 188M 246G 1% /media/BACKUP
On dirait que je l'ai fait. L’espace disponible est passé de 233 à 245,9 Gio. gparted ne se souciait pas du tout, montrant exactement la même information! (inutile de poster une capture d'écran identique)
Quel désordre énorme!
J'ai essayé de le documenter du mieux que je pouvais ... Alors, s'il vous plaît, quelqu'un peut-il me donner un indice sur ce qui se passe ici?
- Quels sont ces mystérieux 4.11 GiB manquant de NTFS -> formatage ext4?
- Pourquoi il y a tant de divergences entre gparted, Nautilus, tune2fs, df?
- Quel est le problème avec mes maths? (questions en gras dispersés ce post)
Toute aide est appréciée. Bien que je ne puisse pas comprendre ce qui se passe, j’envisage sérieusement d’abandonner ext4 au profit de NTFS pour tout sauf la partition /.
Merci!
Il y a quelques choses qui se passent ici. gparted indique l'espace réellement utilisé/libre. Le noyau réduit le nombre disponible de l'espace réservé. Une fois que vous avez supprimé l'espace réservé, le compte libre n'a pas changé car les blocs réservés étaient déjà libres. c'est simplement que les utilisateurs non root ne sont pas autorisés à envahir cet espace pour les empêcher de causer des problèmes en remplissant le disque. Les numéros de gnome sont un peu floconneux à cause d'un bug . Au lieu de signaler l'espace utilisé par le noyau (et par df), il le calcule en soustrayant l'espace libre du total. Cela provoque l'affichage de l'espace réservé utilisé.
Les 4 Go manquants sont réellement utilisés, c'est la surcharge fs pour ext4. NTFS n'attribue initialement qu'une petite quantité d'espace à la MFT et l'augmente au besoin. Cependant, la série ext de systèmes de fichiers alloue de l’espace pour la table inode (équivalent approximatif de la MFT) au moment du formatage et ne peut pas croître. L'espace manquant dans l'espace total signalé est la table inode. Le peu d'espace utilisé provient du journal (généralement 128 Mo) et du redimensionnement des inodes.
Tout d'abord, les blocs réservés ne sont pas bloc utilisé pour la gestion interne du système de fichiers.
Les blocs réservés sont simplement réservés pour root, afin de garantir que les services utilisant des fichiers sur cette partition ne peuvent pas être épuisés par un utilisateur non-administrateur occupant tout l'espace.
Même sans blocs réservés (-m 0), il y a toujours une partie de l'espace utilisé pour la gestion interne du système de fichiers, je ne peux pas dire combien, je n'ai pas une connaissance aussi approfondie.
De plus, Gparted est exécuté sous le nom root. Les blocs réservés sont donc considérés comme libres. Nautilus , exécuté en tant qu'utilisateur, voyez-le comme non libre.
Ok, la réponse de @ psusi est très claire, je n'ai rien à ajouter.
Essayez de réduire la taille de la partition de quelques mégaoctets à l'aide de gparted, puis augmentez-la à sa taille d'origine. Cela peut entraîner d'autres applications à lire les tailles correctement. J'ai récemment corrigé une erreur de 50 Go de cette façon!