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

rsync : exécution un peu longue à mon goût, pourquoi ?

12 réponses
Avatar
Francois Lafont
Bonjour à tous,

Je suis sous Debian Squeeze en 64 bit. J'ai une clé usb formatée en
fat32 qui me sert à sauvegarder les donnés essentielles de mon home. Une
fois que j'ai inséré la clé usb, je lance un petit script maison qui me
sauvegarde certains dossiers sur la clé. Le script consiste en ça :

------------------------------------------------------
rsync -axh --delete --progress --modify-window=2 \
"$HOME/dossier1/" "/media/KEYSAVE/save/dossier1/"

rsync -axh --delete --progress --modify-window=2 \
"$HOME/dossier2/" "/media/KEYSAVE/save/dossier2/"

# etc.
# Puis pour finir :
sync
------------------------------------------------------

J'utilise ce script 2 ou 3 fois par semaines. Et à chaque fois lors
d'une sauvegarde, 98% (au « pifomètre ») des fichiers de la cible (la
clé usb donc) sont inchangés. Pourtant, mon script met du temps je
trouve, comparativement aux modifications assez peu nombreuses à faire
en général. Je vois défiler sur ma console la liste de tous les dossiers
(les sous-dossiers etc.) lorsque le script s'exécute et parfois au
niveau d'un dossier où il n'y absolument aucune modification à apporter,
ça se bloque une minute ou 2, puis ça reprend et tout se termine
normalement. Mon script s'exécute sans erreur à chaque fois.

Chose qui m'intrigue encore plus : quand je relance une deuxième fois le
script juste après une première exécution. Alors là, forcément, il y a 0
changement à effectuer sur la cible et d'ailleurs je vois bien la liste
de tous les dossiers (les sous-dossiers etc.) défiler à toute vitesse.
Mais dès qu'arrive l'exécution de la commande finale « sync », là je
dois attendre une bonne longue minute (voire un peu plus) avant que ça
se termine et que j'ai à nouveau le prompt, alors que sur la cible il
n'y a eu absolument *aucune* modification à apporter. Comment cela se
fait-il ?

Voici quelques éléments utiles peut-être :
- mon /home est monté sur une partition séparée en ext4 (partition qui
est seule sur le disque).
- ma clé est en fat32
- l'ensemble des données sauvegardées sur la clé occupe 2.5 Go environ.

Merci d'avance pour votre aide.


--
François Lafont

10 réponses

1 2
Avatar
Luc.Habert.00__arjf
Francois Lafont :

J'utilise ce script 2 ou 3 fois par semaines. Et à chaque fois lors
d'une sauvegarde, 98% (au « pifomètre ») des fichiers de la cible (la
clé usb donc) sont inchangés. Pourtant, mon script met du temps je
trouve, comparativement aux modifications assez peu nombreuses à faire
en général.



Combien de fichiers as-tu? Si tu en as beaucoup, le simple fait de passer en
revue les fichiers pour obtenir leur taille et date de modif (ce que fait
rsync pour décider si il faut sauvegarder) peut expliquer la lenteur.

Tu peux tester avec strace pour voir ce que fait rsync.

Chose qui m'intrigue encore plus : quand je relance une deuxième fois le
script juste après une première exécution. Alors là, forcément, il y a 0
changement à effectuer sur la cible et d'ailleurs je vois bien la liste
de tous les dossiers (les sous-dossiers etc.) défiler à toute vitesse.



J'imagine que les métadonnées sont dans le cache du filesystem, donc ça va
largement plus vite.

Mais dès qu'arrive l'exécution de la commande finale « sync », là je
dois attendre une bonne longue minute (voire un peu plus) avant que ça
se termine et que j'ai à nouveau le prompt, alors que sur la cible il
n'y a eu absolument *aucune* modification à apporter.



Peut-être que le noyau met à jour la date de dernier accès aux fichers et
répertoires. Est-ce que ta clef est montée avec noatime?
Avatar
Francois Lafont
Salut,

Le 19/01/2012 23:57, Luc Habert a écrit :

J'utilise ce script 2 ou 3 fois par semaines. Et à chaque fois lors
d'une sauvegarde, 98% (au « pifomètre ») des fichiers de la cible (la
clé usb donc) sont inchangés. Pourtant, mon script met du temps je
trouve, comparativement aux modifications assez peu nombreuses à faire
en général.



Combien de fichiers as-tu?



$ find /media/KEYSAVE/save/ -type f | wc -l
8963

Si tu en as beaucoup, le simple fait de passer en
revue les fichiers pour obtenir leur taille et date de modif (ce que fait
rsync pour décider si il faut sauvegarder) peut expliquer la lenteur.



Je pensais qu'il se contentait de regarder la date modif uniquement, non ?

Tu peux tester avec strace pour voir ce que fait rsync.



Encore lui... décidément. :-)
Bon, le fichier ne fait que 469 lignes. Je me permets de le poster en
fin de message. Perso, ça ne me parle pas trop encore une fois.

Chose qui m'intrigue encore plus : quand je relance une deuxième fois le
script juste après une première exécution. Alors là, forcément, il y a 0
changement à effectuer sur la cible et d'ailleurs je vois bien la liste
de tous les dossiers (les sous-dossiers etc.) défiler à toute vitesse.



J'imagine que les métadonnées sont dans le cache du filesystem, donc ça va
largement plus vite.



Plutôt qu'une histoire de cache, je pensais que la rapidité lors de
cette phase du script s'expliquait tout simplement par l'absence de
fichier à modifier.

Mais dès qu'arrive l'exécution de la commande finale « sync », là je
dois attendre une bonne longue minute (voire un peu plus) avant que ça
se termine et que j'ai à nouveau le prompt, alors que sur la cible il
n'y a eu absolument *aucune* modification à apporter.



Peut-être que le noyau met à jour la date de dernier accès aux fichers et
répertoires. Est-ce que ta clef est montée avec noatime?



Ah, ça pourrait expliquer. En fait, je n'ai absolument rien paramétré au
niveau du montage de ma clé. Je suis sous Gnome 2.3 et je crois qu'il
s'occupe lui-même de monter ma clé automatiquement dès que je la
branche. J'ai ça ensuite :

$ mount | grep KEYSAVE
/dev/sdc on /media/KEYSAVE type vfat
(rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush)

A priori pas d'option noatime donc. J'ai alors démonté la clé sous root
avec la commande umount puis je l'ai remontée avec la commande :

mount -t vfat /dev/sdc /media/KEYSAVE/ -o
noatime,rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush

Mais je n'ai pas constaté d'amélioration notable ensuite. Par exemple,
après une deuxième exécution du script, tout a défilé très vite sans que
la moindre modif ne soit faite (comme avant sans l'option noatime), mais
au moment de la commande sync je me retrouve avec une attente de une ou
deux minutes (comme avant sans l'option noatime).


Contenu de "out" après l'exécution de :
strace -o out Sauvegarde_cle_usb.bash

-------------------------------------------------------
execve("/home/francois/MesDocs/bin/Sauvegarde_cle_usb.bash",
["Sauvegarde_cle_usb.bash"], [/* 41 vars */]) = 0
brk(0) = 0x15c5000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f55fe48d000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size™718, ...}) = 0
mmap(NULL, 99718, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f55fe474000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3,
"177ELF211 3 >
Avatar
Luc.Habert.00__arjf
Francois Lafont :

$ find /media/KEYSAVE/save/ -type f | wc -l
8963



Bon, c'est pas rien mais pas énorme non plus.

Je pensais qu'il se contentait de regarder la date modif uniquement, non ?



La page de man parle de la taille aussi (mais les deux s'obtiennent en même
temps, ça ne fait pas plus de travail à la clef).

Bon, le fichier ne fait que 469 lignes. Je me permets de le poster en
fin de message. Perso, ça ne me parle pas trop encore une fois.



Je pensais au strace d'un rsync. Là, c'est le strace du script, et, sans
l'option -f, strace ne trace pas les processus fils, donc il n'y a rien
d'intéressant. Tiens, maintenant que j'y pense, ce serait bien d'ajouter
l'option -tt pour voir le temps pris par les systèmes appels.

Plutôt qu'une histoire de cache, je pensais que la rapidité lors de
cette phase du script s'expliquait tout simplement par l'absence de
fichier à modifier.



Il faut quand même le déterminer, qu'il n'y a pas de fichiers à modifier.

A priori pas d'option noatime donc. J'ai alors démonté la clé sous root
avec la commande umount puis je l'ai remontée avec la commande :

mount -t vfat /dev/sdc /media/KEYSAVE/ -o
noatime,rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush

Mais je n'ai pas constaté d'amélioration notable ensuite.



Grmbl. Bon, la réponse est peut-être dans le strace, sinon, je n'ai pas plus
d'idée.
Avatar
Sergio
Le Thu, 19 Jan 2012 22:57:21 +0000, Luc Habert a écrit :

Peut-être que le noyau met à jour la date de dernier accès aux fichers
et répertoires. Est-ce que ta clef est montée avec noatime?



Ça marche le "atime" avec le FAT32 ?

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
Lucas Levrel
Le 20 janvier 2012, Francois Lafont a écrit :

A priori pas d'option noatime donc. J'ai alors démonté la clé sous root
avec la commande umount puis je l'ai remontée avec la commande :

mount -t vfat /dev/sdc /media/KEYSAVE/ -o
noatime,rw,nosuid,nodev,uhelper=udisks,uid00,gid00,shortname=mixed,dmask 77,utf8=1,showexec,flush

Mais je n'ai pas constaté d'amélioration notable ensuite. Par exemple,
après une deuxième exécution du script, tout a défilé très vite sans que
la moindre modif ne soit faite (comme avant sans l'option noatime), mais
au moment de la commande sync je me retrouve avec une attente de une ou
deux minutes (comme avant sans l'option noatime).



Tu pourrais essayer de monter avec l'option sync, et de virer la commande
du script.

Aussi, le fait que le script « traîne » sur cette commande ne veut pas
dire qu'elle est en cause. J'ai remarqué pendant l'exécution d'rsync que
le listage des fichiers traités s'arrête parfois plusieurs secondes alors
que la dernière ligne affichée est un tout petit fichier ! J'en ai déduit
que la cause est la synchronisation de tout ce qui avait été affiché
avant.

D'après le man, si rsync affiche un dossier c'est qu'il le trouve modifié.
Non ? Essaye aussi l'option de montage nodiratime.

--
LL
Avatar
Fabien LE LEZ
On Thu, 19 Jan 2012 23:20:34 +0100, Francois Lafont
:

rsync -axh --delete --progress --modify-window=2



Si tu utilises une clé en FAT, as-tu vraiment besoin de -a ?
-rt devrait suffire.

Chronomètre le script avec l'option -n. S'il prend autant de temps,
c'est que c'est la lecture qui est longue (probablement, la lecture de
la liste des fichiers sur la clé). S'il est très rapide, c'est que
c'est l'écriture des modifications qui est longue.
Bien sûr, enlève puis remets la clé après chaque test, afin d'éviter
que le cache intervienne.
Avatar
Luc.Habert.00__arjf
Sergio :

Ça marche le "atime" avec le FAT32 ?



Oui. C'est le ctime qui n'a pas d'équivalent en fat.
Avatar
Nicolas George
Luc Habert, dans le message <jfbjqn$m21$, a écrit :
Ça marche le "atime" avec le FAT32 ?


Oui. C'est le ctime qui n'a pas d'équivalent en fat.



FAT n'a qu'un timestamp, il est utilisé pour le mtime. Ce que je dis est
valable pour FAT12 et FAT16, je ne sais pas pour FAT32, mais ça m'étonnerait
vraiment qu'ils aient ajouté un timestamp.
Avatar
moi-meme
Le Thu, 19 Jan 2012 22:57:21 +0000, Luc Habert a écrit :

Combien de fichiers as-tu? Si tu en as beaucoup, le simple fait de
passer en revue les fichiers pour obtenir leur taille et date de modif
(ce que fait rsync pour décider si il faut sauvegarder) peut expliquer
la lenteur.



si je mets un sync derrière la commande rsync (sur une clé USB aussi), il
se passe un temps non négligeable pour que sync se termine.

J'en ai déduit (ai-je raison ?) que c'est le temps du vidage du tampon de
la clé USB.

Par contre je n'ai pas le problème sur mon NAS. Sans doute qu'il n'y a pas
de tampon dans ce cas (liaison par SAMBA).
Avatar
Luc.Habert.00__arjf
moi-meme :

si je mets un sync derrière la commande rsync (sur une clé USB aussi), il
se passe un temps non négligeable pour que sync se termine.

J'en ai déduit (ai-je raison ?) que c'est le temps du vidage du tampon de
la clé USB.



Oui. Tu as le meme effet avec un umount.

Par contre je n'ai pas le problème sur mon NAS. Sans doute qu'il n'y a pas
de tampon dans ce cas (liaison par SAMBA).



J'ose espérer qu'il y a du cache aussi, mais il est peut-etre de taille plus
limitée.
1 2