Pourquoi les systèmes de fichiers ext ne remplissent pas tout l'appareil?

8

Je viens de remarquer qu'aucun des systèmes de fichiers ext {2,3,4} que j'essaie de créer sur un disque dur 500G n'utilise tout l'espace disponible (466G). J'ai également essayé reiser3, xfs, jfs, btrfs et même vfat. Tous créent des fs de taille 466G (comme indiqué par df -h ). Cependant, ext * crée des fs de 459G. La désactivation des blocs réservés augmente l'espace disponible pour l'utilisateur, mais la taille de fs est toujours de 459G.

Il en va de même pour le disque dur 1 To: 932G reiserfs, 917G ext4.

Alors, quelle est cette différence de 1,5%? Pourquoi cela se produit-il et existe-t-il un moyen de faire remplir le volume entier par ext?

UPD: Tous les tests effectués sur la même machine, sur le même disque dur, etc. Peu importe la différence entre le 466G et le marketing 500G. Le problème est qu'il diffère pour différents FS ».

À propos de df - il affiche la taille totale de FS, la taille utilisée et l'espace libre. Dans ce cas, j'ai:

pour reiserfs:

/ dev / sda1 466G 33M 466G 1% / mnt

pour ext4:

/ dev / sda1 459G 198M 435G 1% / mnt

Si je désactive la réservation de bloc racine, 435G passe à 459G - pleine taille de fs (moins 198M). Mais fs lui-même est toujours 459G pour ext4 et 466G pour reiser!

UPD2: Remplir des volumes avec des données réelles via dd:

reiserfs:

fs: ~ # dd if = / dev / zero of = / mnt / 1
dd: запись в «/ mnt / 1»: На устройстве кончилось место
975702649 + 0 записей считано
975702648 + 0 записей написано
 скопировано 499559755776 байт (500 Go), 8705,61 c, 57,4 MB / c

ext2 avec réservation de blocs désactivée (mke2fs -m 0):

fs: ~ # dd if = / dev / zero of = / mnt / 1
dd: запись в «/ mnt / 1»: На устройстве кончилось место
960356153 + 0 записей считано
960356152 + 0 записей написано
 скопировано 491702349824 байта (492 Go), 8870,01 c, 55,4 MB / c

Désolé pour le russe, mais je l'ai exécuté dans les paramètres régionaux par défaut et le répéter est trop long. Peu importe, la sortie dd est évidente.

Il s'avère donc que mke2fs crée vraiment un système de fichiers plus petit que les autres mkfs.

Ineu
la source
2
Theres une certaine quantité de frais généraux avec chaque FS ... je ne sais pas celui qui va vous permettre d'avoir accès à tout l'espace physique disponible sur le disque.
prodigitals
Je vous recommande de changer votre nom d'affichage et de mettre ce qui semble être votre blog dans le champ site Web de votre profil, pour le rendre moins flagrant.
Hello71
1
Bonjour71, merci pour les conseils. Le site Web n'a pas vraiment d'importance, c'est seulement pour openid.
Ineu
Pour une note future, si vous voulez rapidement qu'un programme soit sorti en anglais, utilisez LANG=C fooouLC_ALL=C foo
Alan Pearce
Alan, c'est vrai, merci. Cela peut être même LANG = ou LANG = POSIX. Mais comme je l'ai dit, ce processus prend beaucoup de temps, donc le relancer avec des paramètres régionaux différents juste pour quelques lignes est déraisonnable :) Dans les deux cas, cela pose un problème avec la taille FS pour ext2 :(
Ineu

Réponses:

19

Il y a deux raisons pour lesquelles cela est vrai.

Premièrement, pour une raison ou une autre, les auteurs de systèmes d'exploitation signalent toujours de l'espace libre en termes de système de base 2, et les fabricants de disques durs signalent de l'espace libre en termes de système de base 10. Par exemple, un rédacteur de système d'exploitation appellera 1024 octets (2 ^ 10 octets) par kilo-octet, et une fabrication de disque dur appellera 1 000 octets par kilo-octet. Cette différence est assez mineure pour les kilo-octets, mais une fois que vous atteignez les téraoctets, elle est assez importante. Un rédacteur de système d'exploitation appellera 1099511627776 octets (2 ^ 40 octets) par téraoctet, et un fabricant de disques durs appellera 1000000000000 octets par téraoctet.

Ces deux façons différentes de parler des tailles entraînent fréquemment beaucoup de confusion.

Il existe un préfixe ISO pris en charge de manière irrégulière pour les tailles binaires . Les interfaces utilisateur conçues avec le nouveau préfixe à l'esprit afficheront TiB, GiB (ou plus généralement XiB) lors de l'affichage des tailles avec un système de préfixe base 2.

Deuxièmement, df -h indique la quantité d'espace disponible pour votre utilisation. Tous les systèmes de fichiers doivent écrire des informations internes pour garder une trace des choses pour vous. Ces informations occupent une partie de l'espace sur votre disque. Pas généralement beaucoup, mais certains. Cela explique également une partie de la perte apparente que vous voyez.

Après avoir modifié votre message pour qu'il soit clair qu'aucune de mes réponses ne répond réellement à votre question, je vais essayer de répondre à votre question ...

Différents systèmes de fichiers utilisent différentes quantités d'espace pour les informations de gestion et signalent cette utilisation de l'espace de différentes manières.

Par exemple, ext2 divise le disque en groupes de cylindres. Ensuite, il pré-alloue de l'espace dans chaque groupe de cylindres pour les inodes et les cartes d'espace libre. ext3 fait la même chose car il s'agit essentiellement de la journalisation ext2 +. Et ext4 fait également la même chose, car il s'agit d'une modification assez simple (et presque rétrocompatible) d'ext3. Et comme cette surcharge de métadonnées est fixée lors de la création ou du redimensionnement du système de fichiers, elle n'est pas signalée comme espace «utilisé». Je soupçonne que cela est également dû au fait que les métadonnées du groupe de cylindres se trouvent à des endroits fixes sur le disque, et sont donc simplement impliquées comme étant utilisées et donc non marquées ou prises en compte dans les cartes en espace libre.

Mais reiserfs ne pré-alloue aucune métadonnée d'aucune sorte. Il n'a pas de limite d'inode qui est fixée lors de la création du système de fichiers car il alloue tous ses inodes à la volée comme il le fait avec les blocs de données. Il a, au plus, besoin de quelques structures décrivant le répertoire racine et une carte d'espace libre quelconque. Il utilise donc beaucoup moins d'espace lorsqu'il ne contient rien.

Mais cela signifie que reiserfs prendra plus d'espace lorsque vous ajoutez des fichiers car il allouera des métadonnées (comme des inodes) ainsi que l'espace de données réel pour le fichier.

Je ne sais pas exactement comment jfs et btrfs suivent l'utilisation de l'espace des métadonnées. Mais je soupçonne qu'ils le suivent plus comme le fait reiserfs. vfat en particulier n'a aucun concept d'inode. Sa carte d'espace libre (dont la taille est fixée lors de la création du système de fichiers (la fameuse table FAT)) stocke une grande partie des données d'un inode, et l'entrée de répertoire (qui est allouée dynamiquement) stocke le reste.

Très varié
la source
2
Il existe une norme ISO pour cela: en.wikipedia.org/wiki/Binary_prefix
Bobby
@Bobby - Ouais, et ça a commencé à apparaître sur les écrans. J'ajouterai cela à ma réponse. Merci!
Omnifarious
8

En plus des problèmes mentionnés par Omnifarious, avec ext2 / 3/4, une certaine quantité d'espace est réservée à root - cet espace réservé ne s'affiche pas dans la sortie de df.

Par exemple, créer un petit système de fichiers (~ 100 Mo) avec des options par défaut, en utilisant ext2 plutôt que 3 ou 4 afin d'ignorer l'espace qui serait autrement pris par le journal:

swann:/tmp# dd if=/dev/zero of=./loop.fs bs=10240 count=10240
swann:/tmp# mkfs.ext2 loop.fs
swann:/tmp# mkdir loop
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     92480   2% /tmp/loop

Ajuster l'option des blocs réservés ( tune2fsl' -moption de définit les blocs réservés en pourcentage, et l' -roption définit les blocs réservés en tant que nombre de blocs):

swann:/tmp# umount loop
swann:/tmp# tune2fs -m 25 loop.fs
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     72000   3% /tmp/loop

swann:/tmp# umount loop
swann:/tmp# tune2fs -m 0 loop.fs
swann:/tmp# mount -text2 -oloop loop.fs loop
swann:/tmp# df loop
Filesystem           1K-blocks      Used Available Use% Mounted on
/tmp/loop.fs             99150      1550     97600   2% /tmp/loop

Comme vous pouvez le voir dans l'exemple ci-dessus, même lorsque vous êtes connecté en tant que root dfn'affiche pas l'espace réservé dans le décompte "Disponible". L'espace réservé n'apparaît pas non plus dans le compte "Utilisé", qu'il soit connecté en tant qu'utilisateur root ou en tant qu'utilisateur moins privilégié. Cela peut parfois créer de la confusion lorsqu'un système de fichiers est presque plein si vous ne vous attendez pas à ces deux faits.

Notez également que tune2fs, malgré son nom, est pertinent pour les systèmes de fichiers ext3 et ext4 ainsi que pour les systèmes ext2.

David Spillett
la source
Merci d'avoir répondu. Non, il ne s'agit pas de blocs réservés. Question mise à jour.
Ineu
0

À propos de la différence entre les systèmes de fichiers, différents systèmes de fichiers organisent les blocs différemment et ont besoin de plus ou moins de données pour identifier et suivre les blocs. La taille des blocs fait également la différence car si vous avez plus ou moins de blocs pour le même espace, vous avez plus ou moins d'espace "perdu". De plus, les systèmes de fichiers regroupent les blocs pour éviter de fragmenter les fichiers et chaque cluster de blocs a un identificateur d'une certaine taille, donc plus ou moins de clusters de blocs utiliseront un espace physique différent sur le disque. La différence réside donc dans la façon dont le système de fichiers organise l'espace physique.

Voici une description pour ext2 et vous pouvez probablement trouver quelque chose de similaire pour reiserfs mais je ne l'ai jamais utilisé donc je n'en ai pas.

laurent
la source
2
Les Reiserfs et les btrfs sont inhabituels dans la mesure où presque toutes les informations de comptabilité sont allouées dynamiquement. Seules les copies de superbloc et les bitmaps d'espace libre sont attribués lors de la configuration du système de fichiers. Bien sûr, cela signifie que la quantité réelle d'espace disponible pour les données est moins déterministe pour ces systèmes de fichiers.
Omnifarious
@Omnifarious +1 - Donc, si je comprends bien sur reiserfs et btrfs, l'espace disponible signalé est plus grand au début mais sera utilisé à la fois avec des données et des informations de comptabilité au lieu de seulement des données, non?
laurent
@ laurent-rpnet - Oui, c'est correct. Dans le cas de btrfs, c'est encore plus intéressant. btrfs peut implémenter le RAID sur une base de fichiers individuels, donc son rapport sur l'espace libre disponible est encore plus difficile à cerner car il ne peut pas simplement supposer qu'il y aura une certaine quantité d'espace supplémentaire utilisé par bloc utilisé pour les données. De plus, il permet des copies basées sur COW très bon marché, donc l'écriture d'un bloc au milieu d'un fichier existant peut allouer de l'espace.
Omnifarious
Et qu'en est-il de XFS, JFS et VFAT? Il est difficile de croire que des fs aussi primitifs que FAT32 sont plus dynamiques que ext4.
Ineu
FAT32 a également des blocs réservés pour l'organisation. Quelle est la signification de la dynamique ici? En cas d'allocation dynamique, FAT32 n'a pas d'allocation dynamique, comme ext et n'affiche pas non plus tous les blocs sur disque disponibles pour les données. Il a également certaines limitations, le système de fichiers ext4 n'a pas de système d'autorisations, alors qu'ext4 a des autorisations POSIX et des listes de contrôle d'accès et que la taille maximale du fichier est de 4 Go sur FAT32 et de 2 To sur ext3 (pas sûr sur ext4 mais devrait être au moins le même).
laurent