Selon Olivier Allard-Jacquin <olivieraj@???>:
> Quoi que... La notions de "sparses" d'un fs ext2/3 parle d'un problème
> de superblock gardé en réserve. D'où ma question : Tu es sûr que ton
> problème viendrait de fichiers creux ?
Salut et merci pour ton aide sur gzip/dd
Non mais je voulais juste éviter ce cas qui a été reporté par quelqu'un sur le
bug report.
Comme les fichiers creux stockés dans un loopback ne descendent plus comme un
fichier creux sur le disque, ça me semblait une piste intéressante.
Effectivement l'option "sparse_super" de l'ext3 concernent des superblock de
réserves.
Je vais créer un autre fs avec un bs=4096 et comparer les fichiers générés par
rpm --rebuilddb.
Pour info: "use --rebuilddb to rebuild the database indices from the installed
package headers."
D'après ce que j'ai compris, chaque fichier /var/lib/rpm/Xxxx est un Berkeley DB
manipulable individuellement par les commandes /usr/lib/rpm/rpmdb_* (dump, load,
recover, verify...)
Je ne sais pas (encore) où sont conservés les "package headers" pour reconstuire
ces DBs.
C'est justement parce que rpm n'est pas sensé être sensible au "block size" du
fs que cela m'intéresse. Ça ressemble à un problème kernel.
Est-ce que quelqu'un connaît un outil qui me permettrait de tester la
consistence d'un file system sur différents aspects: fichiers creux, mmap, ...
Merci d'avance
--
Yves Martin
