Re,

Klaus Knopper a (enfin) porté cloop pour le 2.6. Du coup, on peut faire quelques comparaison, en particulier avec squahfs

cloop est le système de compression de block utilisé pour la knoppix. On met un iso9660 dedans, et on a un fs comprimé.

http://squashfs.sf.net/(...) est un système de fichiers comprimé (chaque fichier est comprimé, et même les inodes) performant, on peut faire des LiveCd avec, aussi. Dans ce cas on fait un montage loop de l'image du fs.

Bref j'ai comparé cloop+iso9660 et loop+squashfs, en utilisation depuis un cdrom.

Accès simple. Les fs montés sur /mnt on fait::
for i in 1 2; do time tar cpPf - /mnt | dd of=/dev/null ; done

Bilan: squashfs est 15% plus rapide environ. Impressionant.

Mais on utilise rarement un fs en lisant les fichiers dans l'ordre. J'ai donc imaginé un autre test.

Création de la liste de fichiers avec un ordre "aléatoire"
find -type f -a -exec md5sum {} \; | sort | awk '{print $2}' > /root/listmd5

puis lecture de tous les fichiers dans cet ordre:
time cat /root/listmd5 | xargs tar cpPf - | dd of=/dev/null

Et là, cloop+iso9660 est 28% plus rapide que squashfs.

J'ai un peu de mal à expliquer ce retournenment. Peut-être le fait que cloop envoie les blocks décomprimés dans le cache block du noyau? Ou juste un problème d'optimisation de squashfs?

J'aurais aimé testé aussi l'encombrement de la mémoire et la charge du cpu, mais j'ai pas d'idées sur la façon de faire. Si quelqu'un a une solution je suis preneur.

> Lire le journal (1 commentaire, moyenne: 1).