Pour une raison quelconque, lorsque je crée un fichier texte sur OS X, il s'agit toujours d'au moins 4 ko, sauf s'il est vide. Pourquoi est-ce? Pourrait-il y avoir 4 000 octets de métadonnées sur 1 octet de texte brut?

La taille de bloc du système de fichiers doit être de 4 ko. Lorsque des données sont écrites dans un fichier contenu dans un système de fichiers, le système d'exploitation doit allouer des blocs de stockage pour contenir les données qui seront écrites dans le fichier.

Généralement, lorsqu'un système de fichiers est créé, la mémoire de stockage contenue dans ce système de fichiers est segmentée en blocs de taille fixe. Cet article de Wikipedia explique brièvement ce processus.

La taille de bloc sous-jacente du système de fichiers pour ce fichier doit avoir une taille de bloc de 4 Ko. Ce fichier utilise 1 bloc de 4 Ko et un seul octet de ce bloc contient les données réelles.

Tous les systèmes de fichiers ont une taille de cluster ou de bloc ou la plus petite quantité d'espace disque pouvant être allouée pour contenir un fichier. Même si la taille du fichier réel est inférieure à la taille du cluster / bloc, il utilisera toujours un cluster ou 4 Ko sur votre système de fichiers. La taille du cluster dépend du système de fichiers et des options du système de fichiers.

Comme Gilles l'a fait remarquer , s'il contient zéro octet, il utilise zéro bloc / cluster, mais un inode sur les systèmes de fichiers * nix typiques, ce qui répond mieux à la mise en garde, à moins que ce ne soit vide.

Une petite expérience pour illustrer ceci:

Tout d’abord, voyons quelle est la taille de bloc réelle de ma partition root ext4 (LVM):

[root@fedora17 blocksize]# dumpe2fs /dev/mapper/vg_fedora17-lv_root | grep -i "block size"
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

Comme prévu, il est de 4096 (4 Ko). Maintenant, créons trois fichiers: le premier est de zéro octet, le second n’est qu’un octet et le troisième est de 4 Ko (la taille du bloc):

[root@fedora17 blocksize]# touch 0_bytes.bin
[root@fedora17 blocksize]# dd if=/dev/zero of=1_byte.bin bs=1 count=1
[root@fedora17 blocksize]# dd if=/dev/zero of=4096_bytes.bin bs=1 count=4096

Maintenant, nous lsle répertoire. Nous utilisons cette -soption pour voir la taille allouée (la colonne la plus à gauche), en nombre de "blocs" de 1024 octets.
_{(ls ne sait pas que la taille réelle du bloc est 4096 - nous pourrions spécifier, --block-sizemais cela redimensionne tout en fonction de cette valeur, et nous voulons aussi voir la taille réelle du fichier en octets)} .

[root@fedora17 blocksize]# ls -ls
total 8
0 -rw-r--r--. 1 root root    0 Jan 21 23:56 0_bytes.bin
4 -rw-r--r--. 1 root root    1 Jan 21 23:38 1_byte.bin
4 -rw-r--r--. 1 root root 4096 Jan 21 23:38 4096_bytes.bin

Deux choses peuvent être notées ici:

• Le fichier zéro octet occupe zéro bloc dans le système de fichiers, confirmant ainsi ce que Giles a déclaré .
• Même si les deux autres fichiers ont des tailles de fichier différentes, ils occupent tous deux 4 * 1024 = un bloc ext4 de 4 Ko.

Fichiers clairsemés

Les fichiers fragmentés sont des fichiers avec de grands blocs de zéros. Étant donné que les données sont connues comme étant nulles, il est inutile de les stocker sur le disque. De cette manière, la taille apparente d'un fichier peut en réalité être supérieure à la taille sur le disque.

Données en ligne

Notez que certains systèmes de fichiers permettent au contenu de très petits fichiers d'être stockés dans l' inode lui-même. Voir Est-il possible de stocker des données directement dans un inode sur un système de fichiers Unix / Linux? .