df, calcul faux ?

Bonjour,

soit la commande df -BM et sa sortie, où l'on peut lire avec stupéfaction que Util + Disponible < 1M-blocks :

Code:

---

1 2 3 4 5 6

Sys. fich. 1M-blocks Util. Disponible Uti% Monté sur /dev/sda2 84357M 33779M 46286M 43% / /dev/sda3 9263M 1364M 7422M 16% /var /dev/sda4 835509M 760064M 32997M 96% /datas /dev/sdb1 827542M 780820M 4680M 100% /media/sdb1 /dev/sdb2 111102M 99067M 6386M 94% /media/sdb2

---

Essayez de faire vit' vit' 33,8 + 46,3 : ça fait 80,1, on est loin des 84,36 annoncés...

Les seules valeurs justes sont des petites valeurs :

Code:

---

1 2	tmpfs 393M 1M 392M 1% /run tmpfs 2693M 1M 2692M 1% /run/shm

---

Là où c'est très très très flagrant, c'est pour sda4 et sdb1, que je remets là pour bien montrer :

Code:

---

1 2	/dev/sda4 835509M 760064M 32997M 96% /datas /dev/sdb1 827542M 780820M 4680M 100% /media/sdb1

---

Les chiffres de la 1re et de la 2e colonne sont à peu près identiques d'une ligne à l'autre, par contre, bonjour l'écart pour la 3e colonne, l'espace disponible.

Mêmes erreurs de calcul avec df -H (j'ai enlevé les 2 dernières colonnes pour alléger) :

Code:

---

1 2 3 4 5 6

Sys. fich. Taille Util. Dispo /dev/sda2 89G 36G 49G /dev/sda3 9,8G 1,5G 7,8G /dev/sda4 877G 797G 35G /dev/sdb1 868G 819G 5,0G /dev/sdb2 117G 104G 6,7G

---

Quelqu'un aurait une idée pour expliquer ça ?
df (GNU coreutils) 8.13 sur Debian Wheezy 32 bits

vu que DF travail au niveau FS il doit afficher des valeurs avant sync si les options de montages sont utilisées ou encore en taille alloue
genre nKbloc non-entierement écrit comptant entier quand même probablement

ca explique aussi en general l ecart entre du et df ...

en plus les affichages non-naturels de la commande font peut etre des arrondis ce qui accentue l effet ?
et ya peut etre aussi les 5% de marge pour limiter les risques d etre a 100% du FS

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

root@baal:~# mkdir /mnt/{1,2,3} root@baal:~# mount /dev/sde1 /mnt/1 root@baal:~# mount /dev/sde2 /mnt/2 root@baal:~# mount /dev/sdf1 /mnt/3 root@baal:~# for i in /mnt/?/ ; do dd if=/dev/zero of=${i}titi bs=1M count=100 ; done 100+0*enregistrements lus 100+0*enregistrements écrits 104857600*octets (105 MB) copiés, 69,7151*s, 1,5 MB/s 100+0*enregistrements lus 100+0*enregistrements écrits 104857600*octets (105 MB) copiés, 107,089*s, 979 kB/s 100+0*enregistrements lus 100+0*enregistrements écrits 104857600*octets (105 MB) copiés, 121,334*s, 864 kB/s root@baal:~# root@baal:~# df /mnt/? Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur /dev/sde1 999320 103684 826824 12% /mnt/1 /dev/sde2 2755624 106600 2489332 5% /mnt/2 /dev/sdf1 15255952 140584 14317368 1% /mnt/3 root@baal:~# dc 103684 826824 + p 930508 106600 2489332 +p 2595932 14317368 140584 +p 14457952 2k 1.05 14457952 * p 15180849.60 q root@baal:~# root@baal:~# umount /mnt/? root@baal:~#

---

meme sur du FS propre tout neuf meme chose donc c est bien lie au FS probablement au journal du fs d ailleurs ce qui explique le faible drift sur petit FS

Ouaip, j'ai pensé à toutes ces choses, et au micmac 1k <> 1024 aussi, ça n'explique pas la différence d'espace libre entre /datas (sda4) et /media/sdb1, surtout si je vous dis que sdb1 est la destination de mon outil de sauvegarde (à base de rsync) de /datas, donc en gros, + ou - les mêmes disques (835 G / 827 G), + ou - la même occupation (760 G / 780 G) et pas du tout le même espace libre ( 33 G vs 4,7 G !)

Code:

---

1 2	/dev/sda4 835509M 760064M 32997M 96% /datas /dev/sdb1 827542M 780820M 4680M 100% /media/sdb1

---

Par ailleurs, 835 G - 760 G = 75 G pour le premier, et pas 33 G.
Et 827 G - 780 G = 47 G pour le second, et pas du tout 4,7 G.

Bonjour,

L'explication vient peut-être de là (extrait man ext4 , mais concerne des options qui existent depuis ext2):

Citation:

---

bsddf|minixdf
Set the behavior for the statfs system call. The minixdf behavior is to return in the f_blocks field the total number of blocks of the
filesystem, while the bsddf behavior (which is the default) is to subtract the overhead blocks used by the ext2 filesystem and not available
for file storage. Thus

% mount /k -o minixdf; df /k; umount /k

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda6 2630655 86954 2412169 3% /k

% mount /k -o bsddf; df /k; umount /k

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda6 2543714 13 2412169 0% /k

(Note that this example shows that one can add command line options to the options given in /etc/fstab.)

---

Code:

---

1 2 3

$ df -k /home Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur /dev/sda2 542382520 311261444 203546396 61% /home

---

utilisé + disponible
311261444 +203546396 = 514807840

542382520 - 514807840 =27574680 -> Il me manque 26 Mégas pour une partition de 517 Mégas (tiens, ça fait 5%...)

Hmm, regardons comment est tuné mon système de fichiers:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

$ sudo tune2fs -l /dev/sda2 | grep -i block Block count: 137791488 Reserved block count: 6889574 Free blocks: 59241967 First block: 0 Block size: 4096 Reserved GDT blocks: 1024 Blocks per group: 32768 Inode blocks per group: 512 Flex block group size: 16 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) Journal backup: inode blocks

---

6889574 * 4K = 27558296 : Les revoilà ! Le système de fichier réserve 5% (valeur par défaut) au compte root.

Le compte root n'est donc pas contraint par cette limite, si l'on souhaite réduire le pourcentage réservé (pas forcément une bonne idée):

Code:

---

sudo tune2fs -m 1 /dev/sda2

---

Il est aussi possible d'autoriser un autre compte que root à remplir le disque (Reserved blocks uid):

Code:

---

sudo tune2fs -u jipete /dev/sda2

---

Merci pour cette piste.

Tout de suite une petite précision-correction, si quelqu'un cherchait les mêmes infos :

Citation:

---

Envoyé par disedorgue

L'explication vient peut-être de là (extrait man ext4 , mais concerne des options qui existent depuis ext2):

---

Vient de man mount, section ext2.

Ensuite, me suis livré à une tentative de décodage :
86941 correspondrait aux blocks utilisés par le fs ext2, et donc non disponibles pour les users.

Car 2630655 (total mode minixdf) - 86941 = 2543714, le total en mode bsddf.

La seule chose qui m'ennuie, c'est que 2543714 - 13 utilisés ne fait pas 2412169, loin de là, et ils le sortent d'où, ce nombre, d'abord ? Du chapeau ?

Ah lala, que de soucis que de soucis... ;)

EDIT : ah, jlliagre a posté pendant que je calculais de mon côté. Bon, on verra la suite demain à tête reposée 8-)

Sur lubuntu, je l'ai bien dans le man ext4, sinon comme jlliagre l'explique, le diff est dans les 5 % réservé à root, mais je reconnais que c'est un vrai sac de noeud.
Et en plus, d'après le man, le bsddf semble être l'option par défaut qui pour moi est le moins intuitif des deux...

C'est pourtant le comportement le plus logique, la colonne disponible porte bien son nom.

"df" n'affiche pas la place réservée pour root parce que justement, cette place n'est pas disponible pour un utilisateur normal, et que cet utilisateur normal ne serait pas content du tout si "df" lui disait qu'il reste de la place mais que ses tentatives d'écriture lui retourneraient un "disk full".

Je ne parle pas de la colonne "disponible" mais de la colonne "utilisé". Je comprends que l'on affiche pas la disponibilité pour le système, quoi que, la commande pourrait évoluer pour l'afficher dans une autre colonne (elle existe peut-être, j'ai pas vérifié). Mais qu'en est-il pour d'autre type de FS étant donné que l'on peut modifié le comportement de statfs ? :aie:

La colonne "Utilisé" indique bien la taille contenant effectivement des données. Elle n'a pas de raison d'inclure la taille réservée mais inutilisée.

Il n'y a pas d'autre colonne prévue pour afficher la taille disponible pour root. Il faut pour qu'elle soit possible une implémentation de "df" qui s'appuie sur "statvfs" (portable, POSIX et qui renvoie les deux informations) au lieu de "statfs" (pas standard et qui ne renvoie qu'une information).

L'option de montage "minixfs" est une bidouille qui est spécifique à Linux et à "ext2/3/4". Elle rend la commande "df" incompatible avec le standard POSIX qui précise:

Citation:

---

<space free>
The total amount of space available within the file system for the creation of new files by unprivileged users, in 512-byte units. When this figure is less than or equal to zero, it shall not be possible to create any new files on the file system without first deleting others, unless the process has appropriate privileges. The figure written may be less than zero.

---

Bonjour à tous,

"la nuit porte conseil" --> c'est un joyeux foutoir, cette affaire.

Alors tout d'abord,

Citation:

---

Envoyé par disedorgue

Sur lubuntu, je l'ai bien dans le man ext4,

---

man ext4 n'existe pas chez moi. :calim2:

Ensuite, une question :

Citation:

---

Envoyé par jlliagre

6889574 * 4K = 27558296 : Les revoilà ! Le système de fichier réserve 5% (valeur par défaut) au compte root.

---

c'est quoi ce 4 (et je suppose que 4K est une faute de frappe) ? Voir mon calcul de réservation un poil plus bas.

J'ai refait les manips avec une partoche à moi, pour retomber sur ses pieds c'est impossible...
Je précise que toutes ces manips ont été effectuées en root pur et dur (oui je sais c'est mal, mais il faut prendre des risques dans la vie, des fois 8-))

Code:

---

1 2 3

df -k /media/sdb1 Sys. fich. 1K-blocks Util. Disponible /dev/sdb1 847402736 799558904 4791548

---

Code:

---

1 2	utilisés + disponi = vraie_taille_utile : 799558904 + 4791548 = 804350452

---

Jusque là ça va mais ça nous fait une belle jambe et ça sert à rien.
Continuons :

Code:

---

1 2 3 4 5

tune2fs -l /dev/sdb1 | grep -i block (+ un peu de ménage dans la sortie pour y voir clair ici) : Block count: 215261439 Reserved block count: 10763071 Free blocks: 11960958 Block size: 4096

---

Réservation :
selon ta méthode, jlliagre,
10763071 * 4 = 43052284 (* 4 : pourquoi * 4 ? -- voir + haut)
plutôt (puisqu'on parle de 5% de réservation [de l'espace total je suppose]) :
215261439 * 5 / 100 = 10763071,95 et la partie décimale saute --> 10763071 blocks réservés, ça correspond.

Donc
215261439 - 10763071 = 204498368 blocks dispo, qu'on ne retrouve pas dans la sortie de df.
Par ailleurs, les free blocks (11960958) sont loin de correspondre aux 4,8 Gb (arrondis) de df : 11960958 * 4096 = 48992083968, soit presque 49 Gb...
Et il est là, mon mystère !

Un petit crochet par la structure statvfs n'arrange pas les choses (code source + bas) :

Code:

---

1 2 3 4

f_bsize : 4096 f_frsize : 4096 f_blocks : 211850684 f_bfree : 11960958

---

Si on retrouve le f_bfree renvoyé par tune2fs, le f_blocks * f_frsize donne 867740401664, presque 868 Gb (c'est un disque de 1 Tb avec 2 partoches dont une petite d'environ 100 Gb : on est dans les clous), on ne retrouve pas l'espace total, loin du compte.
EDIT : 867740401664 / 1024 = 847402736, la valeur remontée par df ! :ccool:
Et 211850684 - 11960958 = 199889726.
199889726 * 4096 / 1024 = 799558904, les blocks utilisés par df.

On va y arriver, on va y arriver... /EDIT

Trouvé sur le web, source disparue, compile très bien avec Geany :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

#include <stdio.h> #include <sys/statvfs.h>   /* structure statvfs : * unsigned long f_bsize; / file system block size * unsigned long f_frsize; / fragment size * fsblkcnt_t f_blocks; / size of fs in f_frsize units * fsblkcnt_t f_bfree; / # free blocks * fsblkcnt_t f_bavail; / # free blocks for non-root * fsfilcnt_t f_files; / # inodes * fsfilcnt_t f_ffree; / # free inodes * fsfilcnt_t f_favail; / # free inodes for non-root * unsigned long f_fsid; / file system ID * unsigned long f_flag; / mount flags * unsigned long f_namemax; / maximum filename length */   int main() { struct statvfs info; if (-1 == statvfs("/media/sdb1", &info)) { perror("statvfs() error"); return 1; }else { printf(" f_bsize : %lu\n", info.f_bsize); printf(" f_frsize : %lu\n", info.f_frsize); printf(" f_blocks : %lu\n", info.f_blocks), printf(" f_bfree : %lu\n", info.f_bfree), printf(" f_files : %lu\n", info.f_files); printf(" f_ffree : %lu\n", info.f_ffree); printf(" f_fsid : %lu\n", info.f_fsid); printf(" f_flag : %lu\n", info.f_flag); printf(" f_namemax : %lu\n", info.f_namemax); return 0; } }

---

Citation:

---

Envoyé par Jipété

c'est quoi ce 4 (et je suppose que 4K est une faute de frappe) ?

---

Non, 4K n'est pas une faute de frappe, c'est une abréviation pour 4KiB = 4096 = 4 * 1024, 1024 étant l'unité de mesure de "df -k".

D'où il sort: je l'avais mis en rouge et en gras mais ça n'a visiblement pas suffi, c'est la taille de bloc du système de fichier:

Code:

---

Block size: 4096

---

Edit: Avec les valeurs que tu affiches, il n'y a pas d'incohérences. On a exactement 5% de réservé et les calculs tombent juste.

Citation:

---

Envoyé par jlliagre

Non, 4K n'est pas une faute de frappe, c'est une abréviation pour 4KiB = 4096 = 4 * 1024, 1024 étant l'unité de mesure de "df -k".

---

C'est le K tout seul qui m'a perturbé...

Citation:

---

Envoyé par jlliagre

Edit: Avec les valeurs que tu affiches, il n'y a pas d'incohérences. On a exactement 5% de réservé et les calculs tombent juste.

---

Sauf avec l'espace libre :

Citation:

---

Envoyé par Jipété

Par ailleurs, les free blocks (11960958) sont loin de correspondre aux 4,8 Gb (arrondis) de df : 11960958 * 4096 = 48992083968, soit presque 49 Gb...
Et il est là, mon mystère !

---

Pourquoi df remonte 4,8 Gb libres :koi:

Calculs sur la base des remontées de statvfs :

Code:

---

1 2 3 4 5 6 7 8

f_blocks * f_frsize = espace total, /1024 = la valeur df 211850684 * 4096 = 867740401664, /1024 = 847402736   f_blocks - f_free = espace occupé, *4096/1024 = les "utilisés" de df 211850684 - 11960958 = 199889726, *4096/1024 = 799558904   f_free * f_frsize = espace libre, /1024 = pas du tout la valeur de df ! 11960958 * 4096 = 48992083968, /1024 = 47843832

---

Tu oublies simplement de soustraire le nombre de blocs réservés du nombre de blocs libres quand tu calcules le nombre de blocs disponibles pour un utilisateur.

Code:

---

(11960958 - 10763071 ) * 4 = 4791548

---

On retrouve exactement la même valeur que celle retournée par "df".

Citation:

---

Envoyé par jlliagre

Tu oublies simplement de soustraire le nombre de blocs réservés du nombre de blocs libres quand tu calcules le nombre de blocs disponibles pour un utilisateur.

---

Bien vu ! :ccool:

Mais comme le disait disedorgue,

Citation:

---

Envoyé par disedorgue

[...] mais je reconnais que c'est un vrai sac de noeud.
Et en plus, d'après le man, le bsddf semble être l'option par défaut qui pour moi est le moins intuitif des deux...

---

Allez hop !, :resolu:

Merci les copains ;)

Salut,

Je voulais approfondir tout ça pour avoir un outil fiable qui m'indiquerait exactement les espaces total, occupé et libre d'une partoche, j'ai donc bricolé avec une vieille petite clé Usb (128 Mo) que je viens de formatter en ext4.
J'ai pris une petite clé comme ça les outils remontent des petits chiffres, c'est plus facile pour s'y retrouver, et il est assez facile et rapide de générer un fichier d'environ 120 Mo pour jouer avec les frontières (variables, on va le voir) de l'espace libre.

Ensuite j'ai utilisé les commandes qu'on a déjà vues, comme df -k /media/usb qui me retourne

Code:

---

1 2	Sys. fich. 1K-blocks Util. Disponible Uti% Monté sur /dev/sdc1 119835 1550 111887 2% /media/usb

---

et je me suis rendu compte que df mélangeait les données de la structure statvfs (voir le petit programme que j'ai donné) :

Code:

---

1 2 3

119 835 = Espace total 1 550 = Espace occupé (sans précisions, donc Root) 111 887 = Espace libre Non Root

---

Là où ça devient rigolo, c'est que 119835 - (111887 + 1550) = 6398 qui correspond au Reserved block count juste ci-dessous !

J'ai donc repris tune2fs -l /dev/sdc1 | grep -i block en ne gardant que les 3 premières lignes de résultat :

Code:

---

1 2 3

Block count: 127976 Reserved block count: 6398 Free blocks: 118285

---

Mais avec ma calculette, 118285 + 6398 = 124683 et pas 127976, il me manque donc 3293 blocks, non répertoriés. Où sont-ils ? Ils sont occupés ? Par qui, par quoi ? Je viens de formatter la clé et rien dans les sorties de df, de tune2fs, de cfdisk et autre fdisk -l ne me donne une direction de recherche...
Je précise que 5% de 127976 donne bien 6398 en arrondissant.

Par ailleurs, ce Block count de 127976 ne colle pas avec le nombre de blocks (119835) de la structure statvfs, alors, à qui se fier ?

Va falloir que je me paluche le code de tune2fs, je sens -- à moins que quelqu'un ne l'ait déjà fait ?

Pourquoi trouves tu rigolo que "119835 - (111887 + 1550) = 6398" corresponde au "Reserved block count" ?

Salut,

Citation:

---

Envoyé par jlliagre

Pourquoi trouves-tu rigolo que "119835 - (111887 + 1550) = 6398" corresponde au "Reserved block count" ?

---

Rigolo dans le sens où l'opération que je réalise devrait retourner 0 (Total = Occupé + Libre, donc Total - (Occupé + Libre) = 0, enfin, c'est ce qu'on m'a appris à l'école) et pas un nombre qu'il faut aller vérifier avec un autre outil (qu'on n'utilise pas tous les jours, en plus).

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

Par ailleurs, l'espace total de df correspond aux Free Blocks de tune2fs (118285) + Espace occupé (sans précisions, donc Root) de df : 118285 + 1550 = 119835.

Ou alors il y a de gros problèmes de traductions dans df ?

Citation:

---

Envoyé par Jipété

Rigolo dans le sens où l'opération que je réalise devrait retourner 0 (Total = Occupé + Libre, donc Total - (Occupé + Libre) = 0, enfin, c'est ce qu'on m'a appris à l'école)

---

Ç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 ?

Citation:

---

Envoyé par jlliagre

Ç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 ?

---

[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]

Bonjour :coucou:

Ou de voir Hilbert occupé pendant son temps libre ?

:pastaper:

Citation:

---

Envoyé par jlliagre

Ç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 :aie:

Citation:

---

Envoyé par jack-ft

[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 ?

Citation:

---

Envoyé par Flodelarab

Bonjour :coucou:

Ou de voir Hilbert occupé pendant son temps libre ?

:pastaper:

---

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

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:

---

[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:

---

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...

Citation:

---

Envoyé par Jipété

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.

Citation:

---

Envoyé par Jipété

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 :aie:

---

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

Citation:

---

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:

---

[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:

---

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.

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:

---

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:

---

1 2 3 4

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

---

Code:

---

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é.

Citation:

---

Envoyé par Jipété

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)

Citation:

---

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.

Citation:

---

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.

Citation:

---

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é.

Citation:

---

Code:

---

1 2 3 4

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

---

Code:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoyé par jlliagre

Quels autres systèmes de fichiers utilises-tu ?

---

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

Citation:

---

Envoyé par jlliagre

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.

Citation:

---

Envoyé par jlliagre

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.

Citation:

---

Envoyé par jlliagre

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:

---

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:

---

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:

---

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...)
Pièce jointe 202653

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é... :koi:
Je ne sais pas comment on peut gérer les choses avec ça, quoi...

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

Citation:

---

Envoyé par Jipété

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.

Citation:

---

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é.

Citation:

---

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.

Citation:

---

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...)
Pièce jointe 202653

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.

Citation:

---

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é... :koi:
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.

Citation:

---

Envoyé par jlliagre

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

---

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

Citation:

---

Envoyé par jlliagre

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.

Citation:

---

Envoyé par jlliagre

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à :ccool:
Je sais maintenant qu'il ne me faudra pas utiliser cet outil.

Citation:

---

Envoyé par jlliagre

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. 8-)
Pièce jointe 202692
(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.

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 :

Citation:

---

> 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.

Citation:

---

Envoyé par Jipété

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.

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:

---

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.

Citation:

---

Envoyé par Jipété

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 %