Bonjour,
Nouvelle question qui fait suite à mes interrogations concernant la corruption
de mon filesystem ext3 sur Debian woody et mes problèmes pour faire fonctionner
la JVM d'IBM dessus.
Finallement après mise-à-jour au kernel 2.4.22 et à la libc6 2.3.2-9,
la JVM d'IBM fonctionne et la corruption de l'ext3 n'est plus à l'ordre du
jour.
J'avais déjà découvert un fichier de log (redirection de stdout, avec trunk
régulier) dont la taille ne semblait pas normale.
Voici donc un autre exemple: un core dump (de la JVM d'IBM ;) ! )
dont la taille par ls diffère du volume retourné par du -k
# stat core
File: "core"
Size: 573480960 Blocks: 11800 IO Block: 4096 Regular File
Device: 306h/774d Inode: 1622232 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 776/ ) Gid: ( 160/ )
Access: Mon Jan 5 19:44:39 2004
Modify: Tue Nov 25 08:52:47 2003
Change: Tue Nov 25 08:56:12 2003
# du -k core
5900 core
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 !
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 ?
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 '*'
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 ?
Si Linux supporte les fichiers creux, tous les outils les supportent-ils ?
Je pense notamment à tar et cp.
Par exemple, j'ai fait une copie du fichier avec rsync et le résultat:
$ stat core
File: "core"
Size: 573480960 Blocks: 1121184 IO Block: 4096 Regular File
Device: 1606h/5638d Inode: 292099 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 776/ ) Gid: ( 160/ )
Access: Mon Jan 5 17:38:25 2004
Modify: Tue Nov 25 08:52:47 2003
Change: Mon Jan 5 12:24:56 2004
Les tailles sont maintenant cohérentes, et les trous semblent toujours
déclarés: voir les * de hexdump sur cette copie:
00078220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0007c210 00 00 00 00 00 00 00 00 00 00 00 00 14 40 00 00 |.............@..|
0007c220 00 40 00 00 42 00 00 00 00 00 00 00 00 00 00 00 |.@..B...........|
0007c230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00080220 00 00 00 00 00 00 00 00 00 00 00 00 d0 79 ca 03 |............ÐyÊ.|
00080230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
03d27bf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 |..............0.|
03d27c00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
20028000 7f 03 00 00 01 00 00 00 01 00 00 00 00 00 00 00 |................|
Finallement, c'est de la place perdue car les blocs sont réservés par l'inode
mais ne contiennent aucune donnée.
Merci d'avance pour vos lumières.
Tout pointeur sur la documentation potentielle relative aux fichiers creux
est le bienvenu (je ne connais pas le mot anglais pour 'fichier creux'...)
A+
--
Yves Martin
