Dans votre courrier du Jan 6, 8:54, vous ecrivez:
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 ne m'etais jamais pose la question car pour moi le concept de fichier a
trous existe depuis le debut en unix, je pense donc qu'il a toujours existe
en linux.
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 crois que tu te fais rouler par l'interface de hexdump. Quand hexdump
affiche une etoile c'est pour economiser le papier, ca signifie que toutes
les lignes manquantes sont identiques a la precedente.
Dans ton cas :
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 |.............@..|
ca veut dire que de 00078220 a juste avant 0007c210 hexdump n'a a afficher
que des contenus indentiques a celui de la ligne 00078220 (donc que des zeros)
Ca veut dire que dans le fichier, il y a soit effectivement des zeros soit
un trou, puisqu'il est impossible en lecture de faire la difference.
Si Linux supporte les fichiers creux, tous les outils les
supportent-ils ?
Bien sur puisqu'un trou est lu par un programme utilisateur comme une suite
de zeros.
Finallement, c'est de la place perdue car les blocs sont réserv
és par l'inode mais ne contiennent aucune donnée.
Non justement l'interet des trous est qu'il n'y a pas de bloc reserve.
Merci d'avance pour vos lumières. Tout pointeur sur la
documentation potentielle relative aux fichiers creux est le
bienvenu
De ce que j'en sais tout ce qu'il y a a savoir sur les trous est
1/ un trou est cree dans un fichier quand on fait
write
seek <plus loin>
write
2/ le trou est read() sous forme de suite de 0
3/ on ne peut detecter un trou que par la difference entre le resultat de
stat et celui de du.
(je ne connais pas le mot anglais pour 'fichier
creux'...)
holey file ou sparse file (celui la tu aurais du le trouver car je suis sur que
tu as deja vu l'expression sparse matrix pour les matrices pleines de zeros.)
--
Amicalement,
-------------------------------------------------------------------------------
Bernard Cassagne Laboratoire CLIPS - IMAG
Domaine Universitaire BP 53 38041 Grenoble CEDEX 9 FRANCE
tel: 04.76.51.46.14 fax: 04.76.44.66.75 e-mail:Bernard.Cassagne@???
