Bonjour,
Le mar 06/01/2004 à 08:54, Yves Martin a écrit :
> Donc 'du' calcule la place occupée sur le disque en fonction du nombre de blocs
> réservés par l'inode. Mais la taille 'size' déclarée est bien supérieure !
Oui, c'est le comportement normal d'un fichier "troué".
> D'où ma question: Linux supporte-t-il maintenant les fichiers creux
> (comme Solaris et d'autres Unix je pense) ? Si oui sur quels filesystems ?
> Et comment cela s'utilise-t-il en C ?
Il les supporte depuis très longtemps, sur ext2, ext3, et je pense
reiserfs, JFS et XFS. Pour créer un fichier à trous, il suffit de faire
un seek() directement à un offset élevé puis de commencer à écrire.
> Je suis perplexe sur la façon dont 'hexdump -C core' m'affiche le contenu du
> fichier - le programme bloque de façon visible sur les "trous", ce qui signifie
> qu'il n'en a pas conscience de part l'API - les trous ne sont pourtant
> pas affichés par de comblement avec 00 mais avec des astérix '*'
Tout d'abord, il est normal qu'un core aie des trous: il représente
l'image de la mémoire vue par le process à un moment donné. La carte
mémoire n'est pas continue sous linux: le code de l'exécutable est à
0x08048000, suivis des mmap() et brk(), les bibliothèques et la mémoire
partagée à 0x40000000, et la pile sous 0xc0000000 (juste avant le
kernel). Le comme il y a plein de mémoire "non mappée" entre ces zones,
elles ne sont pas physiquement écrites dans le fichier. Ça fait des
trous.
Par contre, il n'y a pas de syscall pour savoir si on est en train de
lire un trou ou pas, un read() ou autre retournera toujours 0. Les
astérisques que tu vois sont juste générées par hexdump quand il y a
plusieurs lignes identiques.
> Je suppose donc que lors du dump, le fichier core conserve les adresses de
> l'espace mémoire du programme (qui peut être non continu). Est-ce juste ?
Ah ben c'est ce que je viens d'écrire. Oui.
> Si Linux supporte les fichiers creux, tous les outils les supportent-ils ?
> Je pense notamment à tar et cp.
Certains outils permettent de transformer des suites de 0 en trous, mais
aucun ne permet de faire la différence à posteriori. Le trou est un
détail d'implémentation du filesystem, en quelque sorte. Une sorte de
mauvais algorithme de compression des suites de 0.
> Par exemple, j'ai fait une copie du fichier avec rsync et le résultat:
Dont acte ... tu peux toujours retransformer un fichier plein de 0 en
fichier à trous avec cp --sparse=always.
> Tout pointeur sur la documentation potentielle relative aux fichiers
> creux est le bienvenu (je ne connais pas le mot anglais pour 'fichier
> creux'...)
Cherche "sparse file".
A+,
Xav
