Re: [Un peu hs] temps de copie sur rack usb
Le Jeudi, 16 Mars 2006 19.40, Frédéric Bothamy a écrit :
[snip]
> > > , du pilote USB
> >
> > ça c'est le noyau..?
>
> Oui. À propos, tu utilises quel noyau ? (perso, j'ai déjà eu quelques
> petits problèmes avec l'USB sur les noyaux 2.6.8-2.6.11).
2.6.15-6 de chez kernel.org
> > > ou encore de la
> > > norme USB (il est peut-être possible que le débit soit partagé selon le
> > > nombre de périphériques montés²).
> >
> > c'est possible : le hub du usb 2 alors que mon port est du 1.0. je vais
> > faire des tests en usb 2.
> >
> > > Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?
> >
> > 1ère permutation : 3 tests
> >
> > 4, 3, 15, 21, 31, 38
> > 3, 2, 4, 36, 44, 32
> > 2, 2, 5, 38, 21, 58
> >
> > 2ème permutations : 3 tests
> >
> > 2, 2, 4, 32, 47, 14
> > 3, 2, 6, 31, 46, 29
> > 2, 2, 5, 36, 32, 39
> >
> >
> > etc..
> >
> > bon apparemment, il y a un saut à la 4ème clé puis ça se calme.
>
> C'est tout de même assez préoccupant. Mais je crois que l'explication
> se trouve ci-dessous.
je ne te le fais pas dire ;-)
> > > Est-ce qu'en démontant les clés dans la boucle juste après la copie des
> > > données les résultats sont meilleurs ?
> >
> > non; d'après mes tests, il est plus rapide de tout démonter après la
> > boucle qu'à la fin de la copie. vas comprendre.
>
> En fait, ceci est incorrect : comme le noyau doit de toute façon copier
> les fichiers vers les clés (et que c'est cela qui prend du temps), le
> temps utilisé pour démonter les clés sert en fait à forcer la
> synchronisation des fichiers et donc l'écriture des fichiers.
dans l'hypothèse où la copie n'est pas terminée I presume
> Ce temps
> est incompressible (il peut avoir lieu lors du démontage de chaque clé
> dans la boucle ou lors du démontage de toutes les clés à la fin).
ok, car si j'attends un moment avant de démonter les clés, le démontage est
quasi-instantané.
> > > Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
> > > défaut) ?
> >
> > comme je ne sais pas ce que c'est, ça doit être en asynchrone. D'ailleurs
> > comment tu fais pour passer en synchrone ? peut-être est-ce plus rapide ?
>
> Il suffit d'ajouter sync dans la ligne du fichier /etc/fstab dans les
> options (ou d'ajouter "-o sync" dans la commande mount).
ok merci.
> En fait, ce qui se passe, c'est que le noyau met en cache les fichiers à
> copier sur une clé, le comportement observé est alors me semble assez
> logique : il ne déclenche la copie que quand il est obligé de le faire
> (soit lors de la copie en mode synchrone, soit quand le noyau a besoin
> de ressources ou quand tu démontes les clés en mode asynchrone).
Pourquoi ne le fait-il pas quand je le lui demande ? pourquoi est-ce que quand
la commande cp a terminé, les fichiers ne sont pas *vraiment* copiés ?
> Note : 2s pour copier 50 Mo sur une clé en USB 1, ce n'est pas réaliste.
> :-)
effectivement, pour de l'usb 1 c'est un peu trop rapide..
> D'après http://en.wikipedia.org/wiki/USB, en Full speed, tu peux
> avoir du 1,4 Mo/s, la durée normale devrait donc être environ 35 s, soit
> la durée observée à partir de la 4e clé (à peu près).
Bonne remarque
> Donc, au final, le comportement observé me semble normal bien
> qu'étonnant à première vue.
oui je suis assez d'accord.
> Après, tu peux comparer ce qui est le plus
> rapide entre les modes synchrone et asynchrone, je pense que la
> différence ne sera pas énorme avec un petit avantage pour le mode
> asynchrone (qui peut commencer la mise à jour de la première clé pendant
> la mise en cache des fichiers des autres clés).
je vais encore faire quelques tests pour m'en assurer.
> Un problème très intéressant et inhabituel...
Clairement. C'est d'ailleurs assez intéressant de voir comment un petit
problème de rien du tout débouche finalement sur des considérations sur le
noyau.
>
>
> Fred
Encore merci Fred pour ton intérêt.
Bonne journée
> --
> Comment poser les questions de manière intelligente ?
> http://www.gnurou.org/Writing/SmartQuestionsFr
> Comment signaler efficacement un bug ?
> http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
--
steve
jabber : sdl@jabber.org
Reply to: