Le bit 1 de quoi donc ?
La taille d'un fichier est définie par la différence entre la position 0 et celle de son dernier octet de données.
C'est pour ça qu'en avançant dans le fichier de
n-1 ko et en écrivant 1 ko, le fichier fait au final
n ko.
Ceci étant dit, le système de fichiers n'est pas dupe de ce petit manège.
Si je crée un fichier contenant 16 Ko de données ...
$ dd if=/dev/urandom of=/tmp/random bs=1K count=16
16+0 enregistrements lus
16+0 enregistrements écrits
16384 octets (16 kB) copiés, 0,00830498 s, 2,0 MB/s... il fait bien 16 ko, et on voit que 32 blocs de 512 octets (soit 16 ko) lui ont bien été alloués :
$ stat /tmp/random
File: « /tmp/random »
Size: 16384 Blocks: 32 IO Block: 4096 fichier
Device: fd00h/64768d Inode: 391983 Links: 1
(...)Si je supprime maintenant le fichier pour invalider son i-nœud, et que je recommence l'opération en n'écrivant effectivement qu'un seul ko de données ...
$ rm /tmp/random
$ dd if=/dev/urandom of=/tmp/random bs=1K seek=15 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000592388 s, 1,7 MB/s... il fait toujours 16 ko, mais seuls 8 blocs de 512 octets (soit 4 ko = la taille minimale d'un bloc d'E/S) lui ont effectivement été alloués :
$ stat /tmp/random
File: « /tmp/random »
Size: 16384 Blocks: 8 IO Block: 4096 fichier
Device: fd00h/64768d Inode: 391983 Links: 1
(...)Ce qui dans l'absolu ne change rien, puisque si je demande à lire le fichier, l'OS va me retourner 15 359 zéros avant de me donner à lire le dernier ko de données utiles :
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00003c00 30 ff ea 85 e0 e4 94 c2 22 ae fa a8 8c 8d 04 35 |0......."......5|
(...)
00003ff0 a5 ab 9c 1d 3d 5a 4c 13 8b cb 1d ac 4e 67 4c 55 |....=ZL.....NgLU|
00004000Mais bon, c'est un cas un peu tordu.
Du fait de la taille minimale d'un bloc d'E/S, un fichier occupe généralement plus d'espace disque que sa taille effective (ou logique).
