Est-il possible qu'un fichier core de 1 GB ne prenne quasiment pas de
place sur disque?
ay:~> df -T .; ls -l core; rm -f core; ls core; df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hda5 ext3 5621496 4182900 1153032 79% /home
-rw------- 1 lefevre lefevre 1180438528 2003-07-09 09:26 core
ls: core: No such file or directory
zsh: exit 1 ls core
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hda5 ext3 5621496 4174472 1161460 79% /home
i.e. moins de 10 Mo étaient réellement pris sur le disque.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
En fait, un fichier a une taille logique, et une taille physique. La taille logique, c'est ce que tu trouves dans le champs st_size d'un struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir la taille physique, au moins, pas de façon portable. Mais grosso modo, c'est la place que le fichier occupe physiquement sur disque. Et c'est toujours une multiple de la taille d'un bloc d'allocation (qui lui est toujours une multiple de 512).
Tu l'obtiens avec du (disk usage) qui est censé te retourner le champ st_blocks de la "struct stat" (ya des soucis/confusions avec ce champ et st_blksize sous certains systemes parfois, voir le code de GNU du).
À noter que le nombre de blocs n'est pas forcément un int((size + 511) / 512), à cause des trous mais aussi à cause des blocs d'indirection et comme tu dis parce que la taille d'allocation n'est pas forcément 512 (1024 sur ext2 par exemple).
Par exemple, le fichier créé par perl dans l'exemple d'Olivier, chez moi, occupe 4 blocs d'allocations (alors qu'on pourrait s'attendre à ce qu'il n'en occupe qu'un vu q'il n'y a qu'un 'x' à stocker), le champ st_blocks vaut "8", du retourne 8, du -k 4, parce qu'en fait il y a un bloc d'indirection, un bloc de double-indirection, un bloc de triple indirection et le bloc qui contient "x". L'inode va contenir une référence au bloc de triple indirection qui va contenir une référence au bloc de double... etc. C'est comme ça que marchent les sparse files. pour accéder aux offsets avant 2^30, on tombe sur des références de blocks nulles et donc des zero sont renvoyés. Les données réelles sont renvoyées que quand on tombe sur des références à des blocs alloués.
Sous ext2, il y a dans l'inode 12 références directes de blocs de données. Donc tout fichier d'au plus 12 kB occupe autant de block que de kB. Pour un fichier de 13kb, il faut un bloc d'indirection en plus qui lui contient une référence au 13e bloc de données et ainsi de suite. Au delà de 256 + 12 blocs, il faut un block de double indirection, au delà de 12 + 256 + 256 * 256 blocs, il faut un bloc de triple indirection. On ne peut pas acceder ensuite de cette façon à plus de 12 + 256 + 256 ^ 2 + 256 ^ 3 blocks.
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode ou par le nom du fichier dans le répertoire.
Oui, mais généralement, ça nous importe peu. Le (en fait un des) nom du fichier est comptabilisé dans la taille du répertoire. Quant à l'i-node, savoir quelle place il prend importe peu. Il suffit de savoir que le fichier occupe *un* i-node que ce nombre est limité, qu'on en obtient l'état d'occupation par df -i).
Note que si la taille des fichiers non-ordinaires (devices, fifos, /proc...) est souvent "0", ce n'est pas pour autant que "cat le-fichier" ne retournera rien.
En fait, un fichier a une taille logique, et une taille physique. La
taille logique, c'est ce que tu trouves dans le champs st_size d'un
struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre
d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir
la taille physique, au moins, pas de façon portable. Mais grosso modo,
c'est la place que le fichier occupe physiquement sur disque. Et c'est
toujours une multiple de la taille d'un bloc d'allocation (qui lui est
toujours une multiple de 512).
Tu l'obtiens avec du (disk usage) qui est censé te retourner le
champ st_blocks de la "struct stat" (ya des soucis/confusions avec ce
champ et st_blksize sous certains systemes parfois, voir le code
de GNU du).
À noter que le nombre de blocs n'est pas forcément un int((size
+ 511) / 512), à cause des trous mais aussi à cause des blocs
d'indirection et comme tu dis parce que la taille d'allocation
n'est pas forcément 512 (1024 sur ext2 par exemple).
Par exemple, le fichier créé par perl dans l'exemple d'Olivier,
chez moi, occupe 4 blocs d'allocations (alors qu'on pourrait
s'attendre à ce qu'il n'en occupe qu'un vu q'il n'y a qu'un 'x'
à stocker), le champ st_blocks vaut "8", du retourne 8, du -k 4,
parce qu'en fait il y a un bloc d'indirection, un bloc de
double-indirection, un bloc de triple indirection et le bloc qui
contient "x". L'inode va contenir une référence au bloc de
triple indirection qui va contenir une référence au bloc de
double... etc. C'est comme ça que marchent les sparse files.
pour accéder aux offsets avant 2^30, on tombe sur des références
de blocks nulles et donc des zero sont renvoyés. Les données
réelles sont renvoyées que quand on tombe sur des références à
des blocs alloués.
Sous ext2, il y a dans l'inode 12 références directes de blocs
de données. Donc tout fichier d'au plus 12 kB occupe autant de
block que de kB. Pour un fichier de 13kb, il faut un bloc
d'indirection en plus qui lui contient une référence au 13e bloc
de données et ainsi de suite. Au delà de 256 + 12 blocs, il faut
un block de double indirection, au delà de 12 + 256 + 256 * 256
blocs, il faut un bloc de triple indirection. On ne peut pas
acceder ensuite de cette façon à plus de
12 + 256 + 256 ^ 2 + 256 ^ 3 blocks.
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode
ou par le nom du fichier dans le répertoire.
Oui, mais généralement, ça nous importe peu. Le (en fait un des)
nom du fichier est comptabilisé dans la taille du répertoire.
Quant à l'i-node, savoir quelle place il prend importe peu. Il
suffit de savoir que le fichier occupe *un* i-node que ce nombre
est limité, qu'on en obtient l'état d'occupation par df -i).
Note que si la taille des fichiers non-ordinaires (devices,
fifos, /proc...) est souvent "0", ce n'est pas pour autant que
"cat le-fichier" ne retournera rien.
En fait, un fichier a une taille logique, et une taille physique. La taille logique, c'est ce que tu trouves dans le champs st_size d'un struct stat ; c'est aussi ce qu'affiche ls. Elle correspond au nombre d'octets que tu pourrais lire. Tu n'as normalement pas de moyen de voir la taille physique, au moins, pas de façon portable. Mais grosso modo, c'est la place que le fichier occupe physiquement sur disque. Et c'est toujours une multiple de la taille d'un bloc d'allocation (qui lui est toujours une multiple de 512).
Tu l'obtiens avec du (disk usage) qui est censé te retourner le champ st_blocks de la "struct stat" (ya des soucis/confusions avec ce champ et st_blksize sous certains systemes parfois, voir le code de GNU du).
À noter que le nombre de blocs n'est pas forcément un int((size + 511) / 512), à cause des trous mais aussi à cause des blocs d'indirection et comme tu dis parce que la taille d'allocation n'est pas forcément 512 (1024 sur ext2 par exemple).
Par exemple, le fichier créé par perl dans l'exemple d'Olivier, chez moi, occupe 4 blocs d'allocations (alors qu'on pourrait s'attendre à ce qu'il n'en occupe qu'un vu q'il n'y a qu'un 'x' à stocker), le champ st_blocks vaut "8", du retourne 8, du -k 4, parce qu'en fait il y a un bloc d'indirection, un bloc de double-indirection, un bloc de triple indirection et le bloc qui contient "x". L'inode va contenir une référence au bloc de triple indirection qui va contenir une référence au bloc de double... etc. C'est comme ça que marchent les sparse files. pour accéder aux offsets avant 2^30, on tombe sur des références de blocks nulles et donc des zero sont renvoyés. Les données réelles sont renvoyées que quand on tombe sur des références à des blocs alloués.
Sous ext2, il y a dans l'inode 12 références directes de blocs de données. Donc tout fichier d'au plus 12 kB occupe autant de block que de kB. Pour un fichier de 13kb, il faut un bloc d'indirection en plus qui lui contient une référence au 13e bloc de données et ainsi de suite. Au delà de 256 + 12 blocs, il faut un block de double indirection, au delà de 12 + 256 + 256 * 256 blocs, il faut un bloc de triple indirection. On ne peut pas acceder ensuite de cette façon à plus de 12 + 256 + 256 ^ 2 + 256 ^ 3 blocks.
Ni l'une ni l'autre ne prend en compte les octets occupés par le inode ou par le nom du fichier dans le répertoire.
Oui, mais généralement, ça nous importe peu. Le (en fait un des) nom du fichier est comptabilisé dans la taille du répertoire. Quant à l'i-node, savoir quelle place il prend importe peu. Il suffit de savoir que le fichier occupe *un* i-node que ce nombre est limité, qu'on en obtient l'état d'occupation par df -i).
Note que si la taille des fichiers non-ordinaires (devices, fifos, /proc...) est souvent "0", ce n'est pas pour autant que "cat le-fichier" ne retournera rien.
