Le stat l'outil de ligne de commande utilise le stat / fstat etc., qui renvoient des données dans le stat structure. Le st_blocks membre du stat la structure renvoie :
Le nombre total de blocs physiques de taille 512 octets réellement alloués sur le disque. Ce champ n'est pas défini pour les fichiers spéciaux de bloc ou spéciaux de caractère.
Ainsi, pour votre exemple "Email", avec une taille de 965 et un nombre de blocs de 8, cela indique que 8*512=4096 octets sont physiquement alloués sur le disque. La raison pour laquelle ce n'est pas 2 est que le système de fichiers sur le disque n'alloue pas d'espace en unités de 512, il les alloue évidemment en unités de 4096. (Et l'unité d'allocation peut varier en fonction de la taille du fichier et de la sophistication du système de fichiers. Par exemple, ZFS prend en charge différents unités d'allocation.)
De même, pour l'exemple wxPython, cela indique que 7056*512 octets, soit 3612672 octets sont physiquement alloués sur le disque. Vous voyez l'idée.
La taille du bloc d'E/S est "un indice quant à la "meilleure" taille d'unité pour les opérations d'E/S" - il s'agit généralement de l'unité d'allocation sur le disque physique. Ne confondez pas le bloc IO et le bloc stat utilise pour indiquer la taille physique; les blocs pour la taille physique sont toujours de 512 octets.
Mise à jour basée sur le commentaire :
Comme je l'ai dit, st_blocks est la façon dont le système d'exploitation indique la quantité d'espace utilisée par le fichier sur le disque. Les unités réelles d'allocation sur disque sont le choix du système de fichiers. Par exemple, ZFS peut avoir des blocs d'allocation de taille variable, même dans le même fichier , en raison de la façon dont il alloue les blocs :les fichiers commencent avec une petite taille de bloc, et la taille du bloc continue d'augmenter jusqu'à ce qu'elle atteigne un point particulier. Si le fichier est tronqué ultérieurement, il conservera probablement l'ancienne taille de bloc. Ainsi, en fonction de l'historique du fichier, il peut avoir plusieurs tailles de bloc possibles. Donc, étant donné la taille d'un fichier, il n'est pas toujours évident de savoir pourquoi il a une taille physique particulière.
Exemple concret :sur ma box Solaris, avec un système de fichiers ZFS, je peux créer un fichier très court :
$ echo foo > test
$ stat test
Size: 4 Blocks: 2 IO Block: 512 regular file
(irrelevant details omitted)
OK, petit fichier, 2 blocs, l'utilisation du disque physique est de 1024 pour ce fichier.
$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
Size: 32768 Blocks: 65 IO Block: 32768 regular file
OK, nous voyons maintenant une utilisation du disque physique de 32,5 Ko et une taille de bloc d'E/S de 32 Ko. Je l'ai ensuite copié dans test3 et tronqué ce test3 fichier dans un éditeur :
$ cp test2 test3
$ joe -hex test3
$ stat test3
Size: 4 Blocks: 65 IO Block: 32768 regular file
Eh bien, voici un fichier contenant 4 octets - tout comme test - mais il utilise physiquement 32,5 Ko sur le disque, en raison de la façon dont le système de fichiers ZFS alloue de l'espace. La taille des blocs augmente à mesure que le fichier grossit, mais elle ne diminue pas lorsque le fichier devient plus petit. (Et oui, cela peut entraîner un gaspillage d'espace substantiel en fonction des types de fichiers et des opérations de fichiers que vous effectuez sur ZFS, c'est pourquoi il vous permet de définir la taille de bloc maximale par système de fichiers et de la modifier dynamiquement.)
J'espère que vous pouvez maintenant comprendre qu'il n'y a pas nécessairement de relation simple entre la taille du fichier et l'utilisation du disque physique. Même dans ce qui précède, la raison pour laquelle 32,5 Ko sont nécessaires pour stocker un fichier d'une taille exacte de 32 Ko n'est pas claire - il semble que ZFS ait généralement besoin de 512 octets supplémentaires pour son propre stockage supplémentaire. Peut-être utilise-t-il ce stockage pour les sommes de contrôle, les décomptes de références, l'état des transactions - la comptabilité du système de fichiers. En incluant ces extras dans la taille de fichier physique indiquée, il semble que ZFS essaie de ne pas induire l'utilisateur en erreur quant aux coûts physiques du fichier. Cela ne veut pas dire qu'il est trivial de rétro-concevoir le calcul sans connaître les détails intimes de l'implémentation du système de fichiers sous-jacent.