Discussion :

[Flodelarab]

Bonjour

Ou de voir Hilbert occupé pendant son temps libre ?

[Jipété]

Ça ne t'est jamais arrivé d'aller dans un restaurant, de voir des tables inoccupées et qu'on te dise qu'il ne restait plus de tables libres ?

Ouais mais en général je change de crémerie, comme on dit, surtout quand selon le serveur auquel tu t'adresses le menu n'est pas le même

[HS]ou d'aller à l'Hôtel de Hilbert, de voir que toutes les chambres sont occupées et qu'on te dise qu'on peut quand même t'accueillir?[/HS]

Bon sang, où j'ai foutu mon aspirine ?

Bonjour

Ou de voir Hilbert occupé pendant son temps libre ?

Je vais lui filer ma pagaille à débrouiller, ça va l'occuper,

J'en suis là, en reprenant les choses à la base, et ça ressemble plus à des sables mouvants qu'à du béton vibré, àmha...

Quand je mets ma clé de 128 Mo et que j'appelle dmesg, je peux lire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[sdc] 256000 512-byte logical blocks: (131 MB/125 MiB)

C'est d'ailleurs confirmé par
blockdev --getpbsz /dev/sdc et blockdev --getss /dev/sdc qui retournent aussi 512.

Là où ça devient rigolo c'est que blockdev --getbsz /dev/sdc retourne 4096,
(--getbsz = Print blocksize in bytes d'après man blockdev)
et tune2fs -l /dev/sdc1 retourne Block size: 1024

D'où sortent ces deux nombres ?, puisque cat /sys/block/sdc/queue/logical_block_size retourne 512,
tout comme cat /sys/block/sdc/queue/physical_block_size.

Le drame c'est que cat /proc/partitions retourne des valeurs qui obligent à admettre que block_size est égal à 1024 sinon ça coince :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
major minor  #blocks  name
   8       32     128000 sdc
   8       33     126976 sdc1

128000 * 1024 = 256000 * 512 (remonté par dmesg comme par cat /sys/block/sdc/size).

Je fatigue, d'autant plus qu'examiner les sources de tune2fs.c n'apporte rien...

[jlliagre]

Autre outil qui remonte cette valeur, OK, mais qui en remonte d'autres dont on ne sait pas trop à quoi elles correspondent, le Block count par exemple, dont on pourrait penser que c'est l'espace total mais il ne correspond pas à celui remonté par df

Les deux valeurs retournées sont différentes tout simplement parce qu'elles ne correspondent pas au même point de vue.

"df" considère que le nombre de blocs total, c'est le nombre de blocs susceptibles de contenir des données plus une partie directement liée à ces données (celle qui est affichée comme taille utilisée alors que le système de fichiers est vide, et que tu appelles "sans précisions donc root". Ce sont en fait probablement les blocs de tables de groupes) tandis que tune2fs indique le nombre de blocs total du périphérique utilisé, toutes catégories confondues.

Il faut que tu sois conscient qu'une partie de ces blocs ne pourra jamais contenir de données par conception. On y trouve par exemple, le journal, la table des inodes, les bitmaps d'inodes et de blocs, les superblocs et autres joyeusetés.

Puisque la métaphore du restaurant à eu un peu de succès, je vais t'en proposer une autre du même style.

Si un système de fichiers était un hotel et un bloc une chambre dans cet hotel, df te retournerait le nombre total de chambres susceptibles d'héberger des clients (total), le nombre de chambres effectivement occupées par des clients (used) et le nombre de chambres disponibles (available, n'incluant pas les chambres inoccupées mais réservées). En revanche, tune2fs te retournerait les informations du point de vue de l'architecte, pour qui toute pièce indispensable au bon fonctionnement de l'hotel doit être comptabilisée, y compris les chambres du personnel, le restaurant, les bureaux, la réception, les divers locaux utilisés par le personnel, les couloirs, etc. La métaphore n'est pas idéale car toutes les pièces d'un hotel n'ont pas la même taille, contrairement aux blocs d'un système de fichier, mais on pourrait parler de mètres carrés: on ne peut pas mettre 100 chambres de 10 m² dans un hotel d'une superficie totale de 1000 m²...

Je t'invite à lire ce document si tu souhaites approfondir ta connaissance d'ext4.

[jlliagre]

Ouais mais en général je change de crémerie, comme on dit, surtout quand selon le serveur auquel tu t'adresses le menu n'est pas le même

Si tu préfères les restaurants qui donnent la table que tu as réservée à quelqu'un d'autre, libre à toi ...

J'en suis là, en reprenant les choses à la base, et ça ressemble plus à des sables mouvants qu'à du béton vibré, àmha...

Quand je mets ma clé de 128 Mo et que j'appelle dmesg, je peux lire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[sdc] 256000 512-byte logical blocks: (131 MB/125 MiB)

C'est d'ailleurs confirmé par
blockdev --getpbsz /dev/sdc et blockdev --getss /dev/sdc qui retournent aussi 512.

Là où ça devient rigolo c'est que blockdev --getbsz /dev/sdc retourne 4096,
(--getbsz = Print blocksize in bytes d'après man blockdev)
et tune2fs -l /dev/sdc1 retourne Block size: 1024

D'où sortent ces deux nombres ?, puisque cat /sys/block/sdc/queue/logical_block_size retourne 512,
tout comme cat /sys/block/sdc/queue/physical_block_size.

Le drame c'est que cat /proc/partitions retourne des valeurs qui obligent à admettre que block_size est égal à 1024 sinon ça coince :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
major minor  #blocks  name
   8       32     128000 sdc
   8       33     126976 sdc1

128000 * 1024 = 256000 * 512 (remonté par dmesg comme par cat /sys/block/sdc/size).

Pourquoi tiens-tu absolument à ce que des utilitaires différents soient obligés de s'accorder sur la taille que doit avoir un bloc ?

La taille d'un bloc, chaque programme ou matériel est libre de la définir comme ça l'arrange.

POSIX définit la taille d'un bloc de périphérique à 512 octets.
Les constructeurs de disques dur sont en train de passer d'une taille de bloc (secteur) de 512 octets à 4096 octets
Les éditeurs de systèmes de fichiers choisissent la taille de bloc qui les arrange.

Pour des raisons de performance et de bon sens, la seule recommandation est que les tailles de blocs utilisées par des utilitaires de haut niveau soient des multiples en puissance de 2 (x1, x2, x4, x8, etc.) de la taille utilisée par le niveau inférieur. Rien n'interdit non plus d'avoir des tailles de bloc (ou d'enregistrement) variables, comme le fait ZFS par exemple avec une taille par de 128k (voire 1 Mo) mais réduite dynamiquement jusqu'à 4k pour les petits fichiers.

[Jipété]

Yop !

Pour résumer, il y a des données concernant un filesystem monté renvoyées par df par ex, mais la terminologie employée n'est pas précise (cette histoire d'espace disque) et en plus il manque des données pour pouvoir s'y retrouver (le fameux Reserved Block Count). Pour prendre une image, on pourrait dire que si le disque est une voiture et si la voiture a 5 ceintures de sécurité, c'est une 4 places car il lui faut un conducteur, une voiture sans conducteur c'est juste un tas de ferraille.
Rappel : ce qui m'a mis la puce à l'oreille, c'est de constater que deux partoches environ similaires avec un taux d'occupation environ identique renvoyaient des données passablement différentes en terme de disponibilité :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Sys. fich.     1K-blocks     Util. Disponible Uti%
/dev/sda4      855560444 778665504   33428292  96%
/dev/sdb1      847402736 801808980    2541472 100%

Il y a aussi des outils qui remontent les données du device (cat /proc/partitions, tune2fs), mais ce dernier a une curieuse manière de calculer les espaces libre et occupé, ce qui est assez perturbant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
tune2fs -l /dev/sdc1
Block count:              126976
Reserved block count:     6348
Free blocks:              117317

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
126976 - 6348 = 120628 block disponibles
120628 - 117317 free = 3311 blocks occupés par on ne sait trop qui ou quoi...

3311 * 1024 = presque 3,4 Mo sur une clé de 128 Mo, à la louche ça représenterait 27 Go sur un disque de 1 To. Quand même, hein !

Faut que je me fasse une raison...

Merci pour le lien, qui cependant n'aborde absolument pas cette problématique des espaces total, libre, occupé, etc., je pense que tout ça s'appuie sur du ext2 et doit être calculé à partir des inodes, avec qui je n'ai jamais joué.

[jlliagre]

Pour résumer, il y a des données concernant un filesystem monté renvoyées par df par ex, mais la terminologie employée n'est pas précise

Les données sont suffisamment précises pour l'objectif souhaité qui consiste uniquement à donner une idée de la taille de la place restant disponible dans le système de fichier. Il est de toute façon illusoire d'espérer une taille exacte puisque la taille effective dépends de ce que l'on va écrire (un seul gros fichier occupera moins de place qu'une multitude de petits fichiers dont la somme des tailles serait égale à celle du gros fichier)

il manque des données pour pouvoir s'y retrouver (le fameux Reserved Block Count).

df est destiné à être utilisé par des utilisateurs non privilégiés, la taille disponible indiquée par df est la taille qui les concerne, c'est à dire "reserved block count" exclus puisqu'ils n'ont pas le droit de les utiliser.

Pour prendre une image, on pourrait dire que si le disque est une voiture et si la voiture a 5 ceintures de sécurité, c'est une 4 places car il lui faut un conducteur, une voiture sans conducteur c'est juste un tas de ferraille.

Oui, un taxi à cinq places assises n'a que quatre places pour les clients.

Il y a aussi des outils qui remontent les données du device (cat /proc/partitions, tune2fs), mais ce dernier a une curieuse manière de calculer les espaces libre et occupé, ce qui est assez perturbant :

Toutes les informations permettant de calculer le surcoût du système de fichier sont retournées par tune2fs. Il donne par exemple le nombre d'inodes et la taille d'un inode, une simple multiplication permet de calculer la taille prise par cette table qui est la partie la plus importante de l'espace "technique" pré-réservé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
tune2fs -l /dev/sdc1
Block count:              126976
Reserved block count:     6348
Free blocks:              117317

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
126976 - 6348 = 120628 block disponibles
120628 - 117317 free = 3311 blocks occupés par on ne sait trop qui ou quoi...

Je t'ai mis dans ma réponse précédente l'essentiel de ce qui est utilisé en interne: le journal, la table des inodes, les bitmaps d'inodes et de blocs, les superblocs.

3311 * 1024 = presque 3,4 Mo sur une clé de 128 Mo, à la louche ça représenterait 27 Go sur un disque de 1 To. Quand même, hein !

Quels autres systèmes de fichiers utilises-tu ?

As-tu mesuré combien tu pouvais mettre de données en fonction du système de fichiers utilisé ? (fat32, ntfs, ext2,3,4, btrfs, zfs, xfs, reiserfs, ufs, iso9660, ...)

D'autre part, dans le cas que tu indiques, les blocs réservés font partie des blocs libres.

je pense que tout ça s'appuie sur du ext2 et doit être calculé à partir des inodes, avec qui je n'ai jamais joué.

Il s'agit ext4, pas d'ext2. Il y a quelques différences notables.

[Jipété]

Quels autres systèmes de fichiers utilises-tu ?

Aucun autre, sauf NTFS dans des machines virtuelles pour des vieux XP et 2000.

As-tu mesuré combien tu pouvais mettre de données en fonction du système de fichiers utilisé ? (fat32, ntfs, ext2,3,4, btrfs, zfs, xfs, reiserfs, ufs, iso9660, ...)

Non et je m'en fiche, ce qui m'intéresse c'est la cohérence des informations, voir + bas.

D'autre part, dans le cas que tu indiques, les blocs réservés font partie des blocs libres.

C'est bien ce que je disais : une histoire de terminologie, car pour moi, ce qui est réservé n'est pas libre, et c'est valable pour tout et n'importe quoi dans la vie de tous les jours.

Il s'agit ext4, pas d'ext2. Il y a quelques différences notables.

Oui, au niveau de la journalisation et d'autres choses, mais fondamentalement et concernant ces histoires d'espace disque je n'ai rien vu dans ton lien, 'fin bon, c'est pas grave.


Les dernières manips :

Tu m'as répondu sur tout un tas de points mais tu as zappé le plus important, pour moi, et que je remets donc ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Sys. fich.     1K-blocks     Util. Disponible Uti%
/dev/sda4      855560444 778665504   33428292  96%
/dev/sdb1      847402736 801808980    2541472 100%

Correction : j'ai fait une sauvegarde entre ci-dessus et maintenant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Sys. fich.     1K-blocks     Util. Disponible Uti%
/dev/sda4      855560444 778676340   33417456  96%
/dev/sdb1      847402736 801820308    2530144 100%

Alors, indépendamment du fait que le sdb1 est utilisé à 100 %, il semblerait que je puisse encore y copier un fichier de 2530144 * 1024 = 2,6 GiB
Testons : j'y copie d'abord un fichier de 2 GiB, aucun problème (Dieu merci !)
J'y copie ensuite un fichier de 600 MiB, toujours aucun problème mais d'après df on est mal, là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Sys. fich.     1K-blocks     Util. Disponible Uti%
/dev/sdb1      847402736 804390816          0 100%

Alors comme je suis un guedin, face à cette disponibilité de 0 bloc, ben j'y recopie encore, et sans aucun message d'erreur, un fichier de 2,5 GiB

Donc, si je me place dans la peau de Mme Michu et quoiqu'on en dise, df calcule faux affiche de drôles de choses...

Et là où je suis complètement plié de rire (mais bien ennuyé pour gérer correctement mes espaces disque), c'est que mc me laisse entendre que j'ai encore 39 GiB libres (ce qui pourrait correspondre à peu près aux 10763071 reserved blocks remontés par tune2fs, à peu près car je n'arrive pas à retrouver les GiB à partir des blocs...)


Et j'aurais juste aimé que df me dise la même chose que mc.

Un dernier mot, bien mystérieux : j'ai donc occupé cet espace sur sdb1 puis fait tourner tune2fs pour voir les Free Blocks, puis là, à l'instant je viens de supprimer les fichiers copiés, je fais sync, je rappelle tune2fs et le nombre de Free Blocks n'a pas bougé...
Je ne sais pas comment on peut gérer les choses avec ça, quoi...

[jlliagre]

On peut dire que tu ne lâches pas l'affaire ...

Aucun autre, sauf NTFS dans des machines virtuelles pour des vieux XP et 2000.

Et bien, essaie de faire le même genre de calculs avec Windows et NTFS.

C'est bien ce que je disais : une histoire de terminologie, car pour moi, ce qui est réservé n'est pas libre, et c'est valable pour tout et n'importe quoi dans la vie de tous les jours.

sauf que là, tu es root, donc c'est toi qui a réservé.

Donc, si je me place dans la peau de Mme Michu et quoiqu'on en dise, df calcule faux affiche de drôles de choses...

Madame Michu, elle n'est pas root donc elle ne peut plus rien copier depuis que free est à 0%.
Toi, comme déjà indiqué, tu es root, un administrateur système donc, et on assume que tu maîtrises ce que df affiche.

Et là où je suis complètement plié de rire (mais bien ennuyé pour gérer correctement mes espaces disque), c'est que mc me laisse entendre que j'ai encore 39 GiB libres (ce qui pourrait correspondre à peu près aux 10763071 reserved blocks remontés par tune2fs, à peu près car je n'arrive pas à retrouver les GiB à partir des blocs...)


Et j'aurais juste aimé que df me dise la même chose que mc.

Tu n'a pas compris que les reserved blocks, c'est une valeur constante ici de 5%. Certains de ces blocs peuvent être disponibles pour root, d'autres peuvent être déjà utilisés par root, comme ici, d'où l'incohérence apparente que tu constate.

Un dernier mot, bien mystérieux : j'ai donc occupé cet espace sur sdb1 puis fait tourner tune2fs pour voir les Free Blocks, puis là, à l'instant je viens de supprimer les fichiers copiés, je fais sync, je rappelle tune2fs et le nombre de Free Blocks n'a pas bougé...
Je ne sais pas comment on peut gérer les choses avec ça, quoi...

tune2fs sert à afficher et à modifier la configuration du système de fichier. Les valeurs affichées font partie de la configuration du système de fichier et n'ont rien à voir avec sont état à un instant donné. Pour tune2fs, les blocs libres, ce sont les blocs qui restent quand on a retranché ceux qui servent à autre chose. Qu'ils soient utilisés ou pas n'intervient pas. Si on revient à la métaphore de l'architecte, il indique le comme "free rooms" le nombre de chambres qui pourront servir à loger des clients, le fait que ces chambres soient occupées un jour donné n'a aucune influence sur cette valeur.

[Jipété]

On peut dire que tu ne lâches pas l'affaire ...

Tant que je n'aurais pas totalement compris, en effet je m'accroche

Et bien, essaie de faire le même genre de calculs avec Windows et NTFS.

Pas question ! C'est trop facile : il y a deux API's, disktotal et diskfree (de mémoire), ça a toujours bien fonctionné, depuis mes premiers pas en programmation sous W95 et VB4 puis Delphi3.

tune2fs sert à afficher et à modifier la configuration du système de fichier. Les valeurs affichées font partie de la configuration du système de fichier et n'ont rien à voir avec son état à un instant donné.

Hé ben voilà
Je sais maintenant qu'il ne me faudra pas utiliser cet outil.

Si on revient à la métaphore de l'architecte, il indique comme "free rooms" le nombre de chambres qui pourront servir à loger des clients, le fait que ces chambres soient occupées un jour donné n'a aucune influence sur cette valeur.

Et c'est donc bien un problème de sémantique : l'architecte dessine et fait construire des rooms, c'est l'hôtelier qui détermine celles qui sont free ou pas.

PS : quand on explore le web avec les bons mots-clé, on se rend compte que je ne suis pas le seul à me poser ce genre de question.

Et pour la petite histoire, dès l'arrivée des "camemberts" sous W95 pour indiquer les espaces libre et occupé des disques, je ne les ai pas supportés parce que j'avais plusieurs disques à gérer or tous ces camemberts étant identiques, j'avais du mal lorsque je cherchais vite de la place pour enregistrer un gros fichier : ça n'était pas du tout visuel.
J'ai alors très vite étudié puis développé un outil qui m'affichait tous les disques avec des barres proportionnelles à leurs tailles, barres colorées en fonction de l'occupation, et franchement ça m'a suivi pendant 20 ans sans aucun problème et qu'avec du bonheur.

(j'ai pas tout mis, ça allait jusqu'à N: sur cette machine)

C'est quand j'ai migré sous le pingouin et que j'ai porté mon outil sous Lazarus que les soucis ont commencé, surtout quand un disque s'est retrouvé à 100% d'occupation, d'où ce post.

[chrtophe]

Je trouve intelligent que l'OS réserve 5% au root. J'ai déjà vu des Windows pleins à craquer planter car 0 espaces disques. Windows averti quand-même que le disque sature.

Autre point :

Je ne pense pas que tu puisses comparer à l'octet prêt les résultats de df et de tunefs, df étant un outil haut niveau et tune2fs, un bas niveau, mais je peux me tromper. Tune2fs ne sera pas valable si tu es en reiserFS par exemple.

J'ai trouvé ça :

> On large FS like 100gb default value of "Reserved block count" takes
> 5% of usable disk, can this value be safely changed to 1% and not
> affect a performance ? Is a reservation size of 1gb enough for 100gb
> disk ? And when we have even larger filesystem like 1Tb default
> "Reserved block count" is 50GB, is it an absolutely minimum must
> have reserved number of space for disk performance, or it's just a
> legacy concept which can be adjusted?

If you set the reserved block count to zero, it won't affect
performance much except if you run for long periods of time (with lots
of file creates and deletes) while the filesystem is almost full
(i.e., say above 95%), at which point you'll be subject to
fragmentation problems. Ext4's multi-block allocator is much more
fragmentation resistant, because it tries much harder to find
contiguous blocks, so even if you don't enable the other ext4
features, you'll see better results simply mounting an ext3 filesystem
using ext4 before the filesystem gets completely full.

If you are just using the filesystem for long-term archive, where
files aren't changing very often (i.e., a huge mp3 or video store), it
obviously won't matter.

- Ted

source : https://www.redhat.com/archives/ext3.../msg00026.html

Tu peux donc modifier ce comportement par défaut, par contre ça créé de la fragmentation, sauf en ext4.

[jlliagre]

Pas question ! C'est trop facile : il y a deux API's, disktotal et diskfree (de mémoire), ça a toujours bien fonctionné, depuis mes premiers pas en programmation sous W95 et VB4 puis Delphi3.

Je parlais de la différence entre taille du support et taille totale rapportée par les outils.
Je viens de créer un volume de 100Mo sous windows 7, formatté en NTFS.
La capacité affichée par windows est de 96.9 Mo
Le capacité disponible est de 83.2 Mo alors qu'il n'y a aucun fichier de présent en dehors de la corbeille (vide) qu'il ne veut pas que j'efface.

[Jipété]

Bonjour à tous,

j'ai fait quelques petites manips avec un bricolo développé à partir de la structure statvfs (source d'inspiration, héhéhé ! ), j'ai fini par trouver le piège de df :
Quand on tape df dans un terminal, la sortie ressemble à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Sys. fich.     1K-blocks     Util. Disponible Uti% Monté sur
/dev/sdc1         118867     32271      80248  29% /media/usb

Le piège c'est qu'il faut lire Util. par tous (root + users) | Disponible pour les users

Et quand on arrive à 0 dispo pour les users, root peut continuer à faire les sauvegardes.
Son espace supplémentaire est disponible après calculs depuis la structure stavfs, tout comme il est remonté par tune2fs ou calculable depuis cat /proc/partitions.

Merci à tous, merci pour tout !

PS : incapable de retrouver le % d'utilisation donné par df, par contre : je calcule 27,15 % -- mais c'est pas bien grave.

[jlliagre]

incapable de retrouver le % d'utilisation donné par df, par contre : je calcule 27,15 % -- mais c'est pas bien grave.

Le pourcentage d'utilisation se base sur la taille disponible pour les utilisateurs non root:

utilisé / (taille - 5%) = 32271 / (118867 * 0.95) = 0.28577 arrondi à 29 %