taille de bloc de fichier - différence entre stat et ls

J'ai remarqué que lorsque je fais:

ls -ls file

Il fournit le nombre de blocs, disons 8 blocs.

Quand je fais:

stat file

Je remarque que le nombre de blocs est 16, deux fois le nombre donné par ls.

La taille de bloc sur mon système de fichiers est de 4096. J'ai appris que l'unité arbitraire pour les blocs utilisés par ls est 1024. Est-il correct de dire que stat utilise une unité arbitraire de 512 octets lors du rapport des blocs?

Si oui, y a-t-il une raison à cette incohérence?

J'utilise Ubuntu 11.10 sur un système de fichiers ext4.

De nombreux disques ont une taille de secteur de 512 octets, ce qui signifie que toute lecture ou écriture sur le disque transfère un secteur entier de 512 octets à la fois. Il est assez naturel de concevoir des systèmes de fichiers où un secteur n'est pas divisé entre les fichiers (ce qui compliquerait la conception et nuirait aux performances); par conséquent, les systèmes de fichiers ont tendance à utiliser des blocs de 512 octets pour les fichiers. D'où les utilitaires traditionnels tels que lset duindiquent les tailles en unités de blocs de 512 octets.

Pour les humains, les unités de 512 octets ne sont pas très significatives. 1 Ko est du même ordre de grandeur et beaucoup plus significatif. Un bloc de système de fichiers (la plus petite unité dans laquelle un fichier est divisé) se compose en fait souvent de plusieurs secteurs: 1 Ko, 2 Ko et 4 Ko sont des tailles de bloc de système de fichiers courantes; ainsi l'unité de 512 octets n'est pas fortement justifiée par la conception du système de fichiers, et il n'y a aucune bonne raison autre que la tradition pour utiliser une unité de 512 octets en dehors d'un pilote de disque.

Vous avez donc une tradition qui n'a pas grand chose à faire, et une convention plus lisible qui se met en place. Un peu comme octal et hexadécimal: il n'y en a pas un qui est vrai et un qui est faux, ce sont des façons différentes d'écrire les mêmes nombres.

De nombreux outils ont une option pour sélectionner les unités d'affichage: ls --block-size=512pour GNU ls, paramétrer POSIXLY_CORRECT=1dans l'environnement pour GNU dfet GNU dupour obtenir des unités de 512 octets (ou passer -kpour forcer des unités de 1 Ko). Ce que la statcommande dans GNU coreutils expose comme la «taille de bloc» (la %Bvaleur) est une valeur dépendante du système d'exploitation d'une interface interne; selon le système d'exploitation, il peut ou non être lié à une taille utilisée par le système de fichiers ou le code du disque (ce n'est généralement pas le cas - voir Différence entre la taille de bloc et la taille de cluster ). Sous Linux, la valeur est 512, indépendamment de ce que fait tout pilote sous-jacent. La valeur de %Bne compte jamais, c'est juste une bizarrerie qu'elle existe du tout.

Après avoir creusé dans le code source et la norme POSIX, je dirais que la réponse de @ antje-m et @Gilles est généralement correcte.

Il vaut la peine de citer le commentaire de POSIX.1-2008 , en résumé:

L'utilisation d'unités de 512 octets est une pratique historique et maintient la compatibilité avec ls et d'autres utilitaires dans ce volume de POSIX.1-2008. Cela n'impose pas que le système de fichiers lui-même soit basé sur des blocs de 512 octets. L'option -k a été ajoutée comme mesure de compromis. Les développeurs standard ont convenu que 512 octets était la meilleure unité par défaut en raison de sa cohérence historique complète sur le système V (par rapport à l'utilisation mixte de 512/1024 octets sur les systèmes BSD), et qu'une option -k pour passer à 1024- unités d'octets était un bon compromis. Les utilisateurs qui préfèrent la quantité de 1024 octets la plus logique peuvent facilement alias df en df -k sans casser de nombreux scripts historiques s'appuyant sur les unités de 512 octets.

Pour la taille de bloc en ls -s:

Le POSIX indique que la taille de bloc par défaut est définie par l'implémentation, sauf si une -koption est donnée.

La taille de bloc par défaut implémentée dans GNU coreutils lsest définie dans GNU gnulib: gnulib/lib/human.c

/* The default block size used for output.  This number may change in
   the future as disks get larger.  */
#ifndef DEFAULT_BLOCK_SIZE
# define DEFAULT_BLOCK_SIZE 1024
#endif

qui provient d'un ancien commit:

commit 96e78d1f64d7c8d2acc5ad27dc3e73b96ae80585
Author: Jim Meyering <jim@meyering.net>
Date:   Mon Jun 29 15:23:04 1998 +0000

Le message de validation lui-même n'a rien dit sur le nombre 1024.

Et notez que la taille de bloc utilisée dans duet dfest également de 1024, lschoisissez simplement de les consister. Bien que pour duet dfc'est une confluence avec la norme POSIX (alors voici la variable d'environnement POSIXLY_CORRECT). Cela semble être une décision de l'équipe GNU, voir la page wikipedia POSIX sur cette controverse.

Pour la commande stat.

Il ne fait pas partie de la norme POSIX, mais l' appel système l' est. Cependant, l'unité de taille de bloc n'est pas standardisée ( sys_stat.h ):stat

L'unité du membre st_blocks de la structure stat n'est pas définie dans POSIX.1-2008.

La statcommande affiche simplement les informations fournies par l' statappel système et utilise la taille de bloc 512 à quelques exceptions près (elles ne sont pas Linux, par exemple HP-UX, IBM AIX, etc. voir les macros définies dans gnulib/lib/stat-size.h).

Le nombre 512 est donc plutôt un choix historique et une convention Linux.

Le GNU coreutils(d'où la lscommande) ne fait pas partie du noyau Linux (d'où l' statappel), il cible différents aspects du système, GNU coreutilsest plus pour l'homme (plus facile à lire), et le noyau Linux pour le résumé matériel (donc plus proche du matériel).

Edit: la taille du bloc 4096 est la taille du "bloc IO", la taille réelle du bloc physique est probablement encore de 512 octets comme expliqué dans cette question .

Les statcommandes utilisent la taille de bloc physique du disque dur. Fondamentalement, tous les disques durs depuis leur création en 1956 ont utilisé des blocs de 512 octets. Cependant, cela a récemment commencé à changer avec l'arrivée du format avancé.

Je soupçonne que lsla taille de bloc de 1024 octets a également une raison historique. Peut-être était-il courant que le système de fichiers ait une taille de bloc de 1024 ou il était utilisé pour vous donner la taille en kilo-octets. Mais (au moins avec GNU coreutils), vous pouvez spécifier la taille du bloc avec l' --block-size=option.