Discussion :

[Jipété]

Bonjour,

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

Code :

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

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 :

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

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 :

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

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 :

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

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

[frp31]

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 :

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

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

[Jipété]

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 :

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

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.

[disedorgue]

Bonjour,

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

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

[jlliagre]

Code :

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

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 :

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

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 :

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

sudo tune2fs -m 1 /dev/sda2

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

Code :

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

sudo tune2fs -u jipete /dev/sda2

[Jipété]

Merci pour cette piste.

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

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

[disedorgue]

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

[jlliagre]

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

[disedorgue]

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 ?

[jlliagre]

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:

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

[Jipété]

Bonjour à tous,

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

Alors tout d'abord,

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

man ext4 n'existe pas chez moi.

Ensuite, une question :

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 )

Code :

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

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

Code :

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

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 :

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

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 :

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

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

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

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;
  }
}

[jlliagre]

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 :

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

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.

[Jipété]

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

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 :

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

Calculs sur la base des remontées de statvfs :

Code :

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

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

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

Code :

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

(11960958 - 10763071 ) * 4 = 4791548

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

[Jipété]

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 !

Mais comme le disait 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 !,

Merci les copains

[Jipété]

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 :

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

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 :

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

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 :

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

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 ?

[jlliagre]

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

[Jipété]

Salut,

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 ?

[jlliagre]

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 ?

[jack-ft]

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