EXT3: Si la taille du bloc est 4K, pourquoi ls -l affiche-t-il les tailles de fichier en dessous?

Si vous exécutez ls -l sur un fichier qui contient une lettre, sa liste sera de 2B. Si votre système de fichiers est en blocs 4k, je pensais qu'il arrondissait les fichiers à la taille du bloc? Est-ce parce que ls -l lit réellement le nombre d'octets dans l'inode? Dans quelles circonstances obtenez-vous arrondi pour bloquer les réponses par rapport au nombre réel d'octets dans les utilitaires GNU du noyau Linux 2.6?

Je suppose que vous avez cette lettre dans le fichier avec echo a > fileou vim file, ce qui signifie que vous aurez cette lettre et un retour à la ligne supplémentaire (deux caractères, donc deux octets). ls -laffiche la taille du fichier en octets, pas en blocs (pour être plus précis: longueur du fichier ):

$ echo a > testfile
$ ls -l testfile
-rw-r--r-- 1 user user 2 Apr 28 22:08 testfile
$ cat -A testfile
a$

(notez que cat -Ales sauts de ligne s'affichent sous forme de $caractère)

Contrairement à ls -l, duaffichera la taille réelle occupée sur le disque:

$ du testfile
4

(en fait, duaffiche la taille en unités de 1 Ko, donc ici, la taille est de 4 × 1024 octets = 4096 octets = 4 Ko, ce qui correspond à la taille de bloc sur ce système de fichiers)

Pour avoir lscela, vous devrez utiliser l' -soption au lieu de / en plus de -l:

$ ls -ls testfile
4 -rw-r--r-- 1 user user 2 Apr 28 22:08 testfile

La première colonne est la taille allouée, toujours en unités de 1 ko. La dernière peut être modifiée en spécifiant --block-size, par exemple

$ ls -ls --block-size=1 testfile
4096 -rw-r--r-- 1 aw aw 2 Apr 28 22:08 testfile

Je pense que la réponse profonde est la suivante:

La longueur de fichier logique et l'espace disque occupé sont des choses vraiment différentes.

Comme le montrent les autres réponses, en principe, un fichier créé avec deux octets a une longueur de deux octets (afficher par ls -l) et occupe 4 Ko (afficher par duou ls -ls).

Voir:

1& [:~/tmp] % echo -n A > test
1& [:~/tmp] % ls -l test
-rw-rw-r-- 1 romano romano 1 Apr 28 14:31 test
1& [:~/tmp] % du test
4 test

Ok, testa une longueur de 1 et une taille (sur le disque) de 4 Ko. Mais:

1& [:~/tmp] % truncate -s +8191 test
1& [:~/tmp] % ls -l test
-rw-rw-r-- 1 romano romano 8192 Apr 28 14:33 test
1& [:~/tmp] % du test
4   test

(la première commande ajoute 8191 zéro octet test), le test a maintenant une longueur de 8192 mais occupe toujours 4 Ko sur le disque (il a un "trou") (1).

Certains systèmes de fichiers peuvent également compacter des fichiers courts afin qu'ils occupent moins d'espace en partageant des blocs (voir par exemple l' empaquetage de queue ) et d'autres comme btrfs copient lors de l'écriture , de sorte que la relation entre un fichier, sa longueur logique et la quantité d'espace qu'il occupe un disque est complexe.

Notes de bas de page:

(1) Ce n'est pas vraiment un trou , c'est à la fin ... mais quand même, ça marche jusqu'à la fin de l'exemple.

ls -lest juste un format long. ls -lsest utilisé pour afficher la taille du bloc.

Essai

echo "1" > 1.txt

bash-3.2$ ls -l 1.txt
-rw-rw-r-- 1 ramesh ramesh 2 Apr 28 15:15 1.txt

Comme nous pouvons le voir, la taille du fichier est indiquée comme 2B. Cependant, si vous devez vérifier la taille du bloc, vous devez exécuter la commande ci-dessous.

bash-3.2$ ls -ls 1.txt
4 -rw-rw-r-- 1 ramesh ramesh 2 Apr 28 15:15 1.txt

Le 4 ci-dessus affiche la taille de bloc utilisée. Nous pouvons également vérifier la même chose en utilisant la statcommande.

bash-3.2$ stat 1.txt
  File: `1.txt'
  Size: 2               Blocks: 8          IO Block: 4096   regular file
Device: 805h/2053d      Inode: 48267720    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  505/  ramesh)   Gid: (  508/  ramesh)
Access: 2014-04-28 15:17:31.000000000 -0500
Modify: 2014-04-28 15:15:58.000000000 -0500
Change: 2014-04-28 15:15:58.000000000 -0500

Maintenant, la question se pose de savoir pourquoi ls -lsrépertorie la taille du bloc comme 4 alors qu'il stataffiche la taille du bloc comme 8. La raison de ce comportement est clairement expliquée dans la réponse ici .

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.