Resize Partition : Calculer la taille minimale Le sujet est résolu

[dezix]

Bonjour,

Je crois bien que c'est une question TABOU
mais je me risque quand-même et uniquement pour ext4 :

La commande :

# resize2fs -M /dev/sdxy

devrait permettre de redimensionner la partition à une taille minimale,
mais le fait très mal,
puisque à une taille très supérieure au véritable minimum possible.

C'est bien connu car on peut lire dans le manuel :

BOGUES CONNUS
La taille minimale du système de fichiers estimée par resize2fs peut ne
pas être correcte, particulièrement pour les systèmes de fichiers avec
une taille de bloc de 1 ko ou 2 ko.

Dans un environnement graphique,
si l'on tente la même opération avec GParted
une taille limite nettement inférieure nous est proposée.

Remarque :

Après l'opération de "retaillage"
GParted affiche un rapport montrant les opérations effectuées,
dont :

# resize2fs -p '/dev/sdxy' <taille_mini>K


Donc pas de doute ,
resize2fs est capable de passer outre son propre minimum.



Ma question :

Comment GParted calcule-t-il son minimum ?

et sinon,
comment calculer un minimum réaliste et acceptable par resize2fs ?

Cette question n'a d'utilité que si l'on ne dispose pas de GParted



Peut-on se baser sur :

Code : Tout sélectionner

# dumpe2fs -h /dev/sdxy
...
Block count:              1834752
Reserved block count:     91737
Free blocks:              630814
...
First block:              0
Block size:               4096
...

en faisant le calcul suivant :

( <Block count> - <Reserved block count> - <Free blocks> ) x <Block size> = <Nbre d'octets utilisés>

Note : <First block> => tant qu'il est à zéro pas de de soucis, sinon ????

Puis se fixer une marge de sécurité... 10 ; 15 ; 20% ?
pour finir avec p.ex:

<Taille mini> = 1.2 x <Nbre d'octets utilisés> ( à diviser par 1000 pour K )



Merci pour vos commentaires et suggestions.

[dezix]

en faisant le calcul suivant :

( <Block count> - <Reserved block count> - <Free blocks> ) x <Block size> = <Nbre d'octets utilisés>

J'ai du écrire une "fausseté"

Sans savoir ce qu'ils représentent exactement (usage interne du système de fichiers journal ; enregistrement des inodes ????)
on ne devrait pas les retrancher car ils sont utilisés d'une certaine façon

donc on aurait simplement :

( <Block count> - <Free blocks> ) x <Block size> = <Nbre d'octets utilisés>


Si cela est confirmé, je rectifierai le 1er message

[dezix]

Au sujet de l'erreur de calcul précédente :

le premier calcul doit correspondre à la valeur de l'espace utilisé par les données/fichiers écrits
c'est à dire ce qui est affiché par la commande : " du - Évaluer l'espace disque occupé par des fichiers "
qui ne tient pas compte des besoins du FS.

La formule du #2 serait donc celle à utiliser pour la taille mini du FS,
à condition qu' elle ne soit pas fondée sur une (autre) erreur de définition ...

[PascalHambourg]

Sans savoir ce qu'ils représentent exactement (usage interne du système de fichiers journal ; enregistrement des inodes ????)
on ne devrait pas les retrancher car ils sont utilisés d'une certaine façon

De quoi parles-tu ? Du "reserved block count" ?
Cette valeur est seulement une limite : si le nombre de blocs libres est inférieur au nombre de blocs réservés, seul l'utilisateur dont l'UID est enregistré (root par défaut) peut allouer des blocs. Elle n'entre pas dans le calcul de l'espace libre ou utilisé. Elle entre seulement dans le calcul de l'espace disponible pour tous les utilisateurs affiché par df.

[dezix]

De quoi parles-tu ? Du "reserved block count" ?
Cette valeur est seulement une limite : si le nombre de blocs libres est inférieur au nombre de blocs réservés, seul l'utilisateur dont l'UID est enregistré (root par défaut) peut allouer des blocs. Elle n'entre pas dans le calcul de l'espace libre ou utilisé. Elle entre seulement dans le calcul de l'espace disponible pour tous les utilisateurs affiché par df.

Donc dois-je comprendre que :

dans la sortie de dumpe2fs le résultat de :

( <Block count> - <Free blocks> )

serait le nombre de blocs utilisés,
donc virtuellement la taille minimale que pourrait prendre le FS sans perte de données ?

Bien sûr on ne retaillera pas aussi juste mais pour la "théorie" ça colle ?

Quel coefficient de majoration appliquer à ce résultat pour une partition dont la taille devrait rester constante ?
... un minimum "prudent" pour éviter les mauvaises surprises après resize2fs

[PascalHambourg]

dans la sortie de dumpe2fs le résultat de :

( <Block count> - <Free blocks> )

serait le nombre de blocs utilisés,
donc virtuellement la taille minimale que pourrait prendre le FS sans perte de données ?

Oui.

Quel coefficient de majoration appliquer à ce résultat pour une partition dont la taille devrait rester constante ?
... un minimum "prudent" pour éviter les mauvaises surprises après resize2fs

Ça dépend de l'usage du système de fichiers. S'il sera toujours utilisé en lecture seule, pas besoin de majorer.
Si seul root écrit dedans, il faut ajouter l'espace nécessaire à l'accroissement prévisible.
Si d'autres utilisateurs écrivent dedans, il faut ajouter en plus l'espace réservé, ou réduire ce dernier avec tune2fs -m ou -r.

[dezix]

Merci, pour ton aide.