Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[Un peu hs] temps de copie sur rack usb

10 réponses
Avatar
steve
Bonjour,

j'ai un hub usb 7 ports o=F9 j'ai branch=E9 6 cl=E9s usb et sur lesquelles =
je vais=20
copier les m=EAmes donn=E9es (env 50M). Comme je vais devoir faire cela pou=
r un=20
grand nombre de cl=E9s, j'ai =E9crit un script shell qui m'automatise tout =
=E7a. En=20
gros, il fait

for i in a b c d e f
do
monte la cl=E9 $i
copie les fichiers
done.

Ce qui est surprenant et qui fait que je m'adresse =E0 vous, c'est que les =
temps=20
de copies augmentent avec le rang de la cl=E9 :

######## N=B0 a

Montage de /dev/sda1 ...
/dev/sda1 mont=E9 sur /media/sda1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 2

######## N=B0 b

Montage de /dev/sdb1 ...
/dev/sdb1 mont=E9 sur /media/sdb1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 7

######## N=B0 c

Montage de /dev/sdc1 ...
/dev/sdc1 mont=E9 sur /media/sdc1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 23

######## N=B0 d

Montage de /dev/sdd1 ...
/dev/sdd1 mont=E9 sur /media/sdd1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 32

######## N=B0 e

Montage de /dev/sde1 ...
/dev/sde1 mont=E9 sur /media/sde1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 30

######## N=B0 f

Montage de /dev/sdf1 ...
/dev/sdf1 mont=E9 sur /media/sdf1 !
DEBUT DE LA COPIE DES FICHIERS...
Temps de copie [s] : 35

Temps total =3D 131 [s]


Et j'imagine que si j'avais une 7e cl=E9, =E7a prendrait plus que 35 second=
es.=20

Donc il y a une grosse perte de temps, car si toutes les copies prenaient l=
e=20
m=EAme temps que la 1=E8re, =E7a ferait une 12aine de secondes plut=F4t que=
131 (donc=20
une perte de pr=E8s de 90%) !

Quelle est la cause de ce ph=E9nom=E8ne ? Comment le corriger afin d'optimi=
ser le=20
processus ? Est-ce en rapport avec le montage des p=E9riph=E9riques ? le no=
yau ?


Quelqu'un a une id=E9e ?


Merci d'avance.

=2D-=20
steve
jabber : sdl@jabber.org

10 réponses

Avatar
Frédéric Bothamy
* steve [2006-03-16 16:29] :
Bonjour,

j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je vais
copier les mêmes données (env 50M). Comme je vais devoir faire cela pour un
grand nombre de clés, j'ai écrit un script shell qui m'automatise tout ça. En
gros, il fait

for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.

Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les temps
de copies augmentent avec le rang de la clé :



[...]

Quelle est la cause de ce phénomène ? Comment le corriger afin d'optimiser le
processus ? Est-ce en rapport avec le montage des périphériques ? le noyau ?



Cela peut venir des clés elles-même (les clés USB peuvent avoir des
vitesses variables selon leur qualité¹), du pilote USB 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²).

Est-ce qu'en changeant l'ordre des clés tu as le même comportement ?

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 ?

Est-ce que tes clés sont montés en synchrone ou asynchrone (mode par
défaut) ?


Fred

¹ cela paraît cependant assez étonnant d'avoir une telle régularité
² je n'ai rien trouvé dans la page http://en.wikipedia.org/wiki/USB qui
pourrait confirmer cela

--
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


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
steve
Le Jeudi, 16 Mars 2006 17.52, Frédéric Bothamy a écrit :
* steve [2006-03-16 16:29] :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.
>
> Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> temps de copies augmentent avec le rang de la clé :

[...]

> Quelle est la cause de ce phénomène ? Comment le corriger afin
> d'optimiser le processus ? Est-ce en rapport avec le montage des
> périphériques ? le noyau ?

Cela peut venir des clés elles-même (les clés USB peuvent avoir des
vitesses variables selon leur qualité¹)



c'est un lot (2400 quand même !) de clé, toutes pareilles.


, du pilote USB



ça c'est le noyau..?

ou encore de la
norme USB (il est peut-être possible que le débit soit partagé selo n 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 fai re
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.



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.


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'ailleu rs
comment tu fais pour passer en synchrone ? peut-être est-ce plus rapide ?



Fred




merci Fred !

¹ cela paraît cependant assez étonnant d'avoir une telle régulari té
² je n'ai rien trouvé dans la page http://en.wikipedia.org/wiki/USB q ui
pourrait confirmer cela
--
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 :
Avatar
steve
Le Jeudi, 16 Mars 2006 16.48, fred a écrit :
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers

peut-être démonter la clé $i ??



j'ai répondu à cette proposition : ça n'accélère rien, au contrai re


--
Fred.



merci !

--
steve
jabber :
Avatar
Frédéric Bothamy
* steve [2006-03-16 18:40] :
Le Jeudi, 16 Mars 2006 17.52, Frédéric Bothamy a écrit :
> * steve [2006-03-16 16:29] :
> > Bonjour,
> >
> > j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquelles je
> > vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> > pour un grand nombre de clés, j'ai écrit un script shell qui m'automatise
> > tout ça. En gros, il fait
> >
> > for i in a b c d e f
> > do
> > monte la clé $i
> > copie les fichiers
> > done.
> >
> > Ce qui est surprenant et qui fait que je m'adresse à vous, c'est que les
> > temps de copies augmentent avec le rang de la clé :
>
> [...]
>
> > Quelle est la cause de ce phénomène ? Comment le corriger afin
> > d'optimiser le processus ? Est-ce en rapport avec le montage des
> > périphériques ? le noyau ?
>
> Cela peut venir des clés elles-même (les clés USB peuvent avoir des
> vitesses variables selon leur qualité¹)

c'est un lot (2400 quand même !) de clé, toutes pareilles.



Ok

> , 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).

> 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.

>
> 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. 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).


> 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).

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).

Note : 2s pour copier 50 Mo sur une clé en USB 1, ce n'est pas réaliste. :-)

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).

Donc, au final, le comportement observé me semble normal bien
qu'étonnant à première vue. 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).

Un problème très intéressant et inhabituel...


Fred

--
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


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Gaëtan PERRIER
Le Thu, 16 Mar 2006 16:29:28 +0100
steve a écrit:

Bonjour,

j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
lesquelles je vais copier les mêmes données (env 50M). Comme je
vais devoir faire cela pour un grand nombre de clés, j'ai écrit un
script shell qui m'automatise tout ça. En gros, il fait

for i in a b c d e f
do
monte la clé $i
copie les fichiers
done.




Et si tu fais dans l'autre sens (f->a) est-ce que ça fait pareil ou est-ce que le temps le plus court est toujours sur sda?

Gaëtan


--
Pensez
Avatar
steve
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 quelqu es
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 comportemen t ?
>
> 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 c opie 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émonta ge 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'ai lleurs
> comment tu fais pour passer en synchrone ? peut-être est-ce plus rapi de ?

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 qu and
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éalis te.
:-)




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, s oit
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é pe ndant
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 s ur 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 :
Avatar
steve
Le Jeudi, 16 Mars 2006 20.49, Gaëtan PERRIER a écrit :
Le Thu, 16 Mar 2006 16:29:28 +0100

steve a écrit:
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur
> lesquelles je vais copier les mêmes données (env 50M). Comme je
> vais devoir faire cela pour un grand nombre de clés, j'ai écr it un
> script shell qui m'automatise tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers
> done.

Et si tu fais dans l'autre sens (f->a) est-ce que ça fait pareil ou est-ce
que le temps le plus court est toujours sur sda?



je n'ai pas encore essayé, mais c'est une bonne idée (que je n'ai pas eue,
grrr). Merci


Gaëtan



--
steve
jabber :
Avatar
Frédéric Bothamy
* steve [2006-03-17 08:24] :

[...]

> 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é.



Oui, c'est normal : la copie réelle qui s'est produite en tâche de fond
s'est terminée avant le démontage des clés, il n'y a donc plus rien à
synchroniser au niveau du système de fichiers et le démontage peut se
faire tout de suite (tu peux également forcer la synchronisation des
systèmes de fichiers avec "sync").

[...]

> 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 ?



C'est le comportement par défaut du noyau d'utiliser le cache du noyau
(en mode asynchrone) plutôt que d'attendre que la copie soit vraiment
terminée (en mode synchrone). Il me semble qu'il y avait eu une
discussion sur LKML pour savoir s'il fallait préférer un mode synchrone
ou asynchrone selon le type de périphérique. La question n'est pas si
évidente même pour des périphériques lents car le mode asynchrone permet
de faire des choses comme ceci :

- copier un fichier sur la clé
- supprimer le fichier

très rapidement (car la copie n'est alors jamais réellement faite) alors
qu'en mode synchrone il faudrait attendre pour les 2 commandes.

C'est alors à l'administrateur de la machine de forcer ou non le mode
synchrone pour certains périphériques.


Fred

--
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


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
steve
Bonjour,


Suite de mon questionnement.

Je me demandais s'il était possible, plutôt que de faire les copies l'u ne
après l'autre (la boucle for), de les faire en parallèle, de manière à
réduire le temps total au temps de copie d'une seule clé.

Existe-t-il une commande genre « pcp » pour "parallèle copy" ?

Merci pour tout conseil, proposition, idée, etc...

Bonne journée


Le Jeudi, 16 Mars 2006 16.48, fred a écrit :
steve a écrit :
> Bonjour,
>
> j'ai un hub usb 7 ports où j'ai branché 6 clés usb et sur lesquel les je
> vais copier les mêmes données (env 50M). Comme je vais devoir faire cela
> pour un grand nombre de clés, j'ai écrit un script shell qui m'auto matise
> tout ça. En gros, il fait
>
> for i in a b c d e f
> do
> monte la clé $i
> copie les fichiers

peut-être démonter la clé $i ??

--
Fred.



--
steve
jabber :
Avatar
Jacques L'helgoualc'h
steve a écrit, lundi 20 mars 2006, à 11:28 :
Bonjour,



bonjour,

Suite de mon questionnement.

Je me demandais s'il était possible, plutôt que de faire les copies l'une
après l'autre (la boucle for), de les faire en parallèle, de manière à
réduire le temps total au temps de copie d'une seule clé.



for i in a b c d e f
do (
monte la clé $i
copie les fichiers
) &
done

Le gain de temps dépendra de la manière dont la bande passante est
partagée --- l'USB n'a pas très bonne réputation en la matière...

Vérifie si certains ports USB n'ont pas le même contrôleur, il y a du
vrai USB2, du faux (= USB1.1), etc.

Merci pour tout conseil, proposition, idée, etc...



de rien,

Bonne journée



merci, aussi.
--
Jacques L'helgoualc'h


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact