Pourquoi un fichier texte occupe-t-il au moins 4 Ko, même s'il ne contient qu'un octet de texte?


47

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?

entrez la description de l'image ici


17
4096 octets, pas 4000.
mécanique

9
@Mechanicalsnail 4095. Vous avez oublié l'octet de données réelles
Tobias Kienzler le

6
@Mechanicalsnail c'est une année bissextile, n'est-ce pas? xkcd.com/394 :P
tkbx

Réponses:


52

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.


10
Un commentaire: sous Windows, la taille de fichier réelle est affichée par défaut et la taille sur le disque est affichée dans le volet Options.
Joe Z.

alors un bloc peut-il accueillir différents fichiers?
Sudeepdino008

@ sudeepdino008 non, un bloc (au moins) pour chaque fichier (le système de fichiers ext de Linux a / avait (?) une option pour mettre plusieurs fichiers dans un bloc, mais il s'agit d'une exception à la règle)
Ro-ee

13

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.


6
"Même si une taille de fichier est égale à zéro octet, elle utilisera toujours un cluster."
Gilles 'SO- arrête d'être méchant'

8

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


Oui, vous avez tout à fait raison. La taille de 4 Ko correspond à la taille utilisée par le système de fichiers pour stocker les informations relatives au stockage du fichier dans le système de fichiers. Des éléments tels que l'index du fichier depuis le début d'un bloc, l'index du bloc et la taille de la mémoire utilisée par le fichier sont stockés et consomment 4k. Cette information est utilisée pour référencer le fichier texte du système de fichiers.
Pvn

3
Ceci est une erreur. Les métadonnées de fichier que vous mentionnez ne "dévorent" aucun des 4 Ko. Ces structures font partie de la surcharge de formatage du système de fichiers. Voir ma réponse ci-dessus pour la preuve. Si ce que vous avez dit était vrai, mon fichier de 4 096 octets nécessiterait plus d'un bloc.
Jonathon Reinhart

Les pointeurs vers le fichier (segment no, blk no) dans le système de fichiers sont les éléments qui doivent être stockés et nécessitent l'attribution d'un bloc. Si le fichier texte contient très peu de contenu pouvant tenir dans le premier bloc qui lui est déjà attribué, il n’exigera pas d’attribution de deuxième bloc. Je conviens que la totalité de 4k n'est pas utilisée pour les métadonnées et qu'une fragmentation interne se produit.
Pvn

3
Je dis qu’aucune taille de bloc de 4 Ko n’est utilisée pour les métadonnées. Je pense que mon exemple le prouve.
Jonathon Reinhart

3
@pvn: Jonathon a raison. Les métadonnées sont stockées dans l'inode du fichier, ce qui est distinct du bloc utilisé pour stocker les données du fichier.
Escargot mécanique
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.