Re: Linux supporte-t-il les fichiers creux ?

Page principale

Répondre à ce message
Auteur: Bernard Cassagne
Date:  
À: guilde
Sujet: Re: Linux supporte-t-il les fichiers creux ?
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@???