Selon Frédéric BOITEUX <fboiteux@???>:
> > Jusqu'à hier, j'étais assez content de supermount... Et hier, j'ai
> > transféré un fichier de 44 Mo depuis ma clef USB (en supermount) et j'ai
> > désespéré du temps que ça a pris (au pif, 10 minutes ?).
> > Mais il faut encore que je compare avec un montage classique pour mettre
> > la faute sur supermount...
>
> Je pense que supermount n'y est pour rien... Il se contente juste de
> lancer automatiquement la commande 'mount', non ?
Non, supermount est un patch dans le kernel qui ajoute un système de
fichiers virtuels dont les options assure le mapping vers le 'vrai'
système de fichier:
none /mnt/cdrom supermount
dev=/dev/hdc,fs=auto,ro,--,iocharset=iso8859-1,codepage=850 0 0
none /mnt/floppy supermount
dev=/dev/fd0,fs=auto,--,iocharset=iso8859-1,sync,codepage=850 0 0
Conséquence: quand on accède à /mnt/cdrom, supermount vérifie que le
système de fichiers n'a pas changé par rapport aux précédents accès.
Je crois aussi avoir remarqué que lorsque l'on éjecte le CD,
les processus qui utilise le point de montage sont killés sans appel.
C'est pratique mais pas tant que cela.
Mon problème est en 'lecture'. Donc aucun impact de 'sync/async'.
J'ai testé sur une autre machine avec le kernel 2.6.3 de la Mdk 10 mais
avec mount manuel: la lecture du même fichier n'a duré que 2/3 minutes.
L'ordre de grandeur est largement différent.
A l'oeil, vu le temps CPU passé dans le système lors de cache copie,
il me semble que supermount est impliqué dans cette baisse de performance.
Si j'analyse encore, je sens qu'il ne me restera que trois alternatives:
- abandonner supermount
- n'utiliser supermount que pour les périphériques read-only
- améliorer supermount
Je vais regarder automountd, ça peut ne pas être mal. Mais le timeout
est génant. Quand je fais une copie sur ma clef USB avant de partir du
boulot, je ne vais pas rester 5 minutes pour attendre automountd ;)
Finallement mount et umount, c'est très bien :|
A+
--
Yves Martin
