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.
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.
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.
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.
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.
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.
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?
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?
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?
$ find /media/KEYSAVE/save/ -type f | wc -l
8963
Je pensais qu'il se contentait de regarder la date modif uniquement, non ?
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.
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.
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.
$ find /media/KEYSAVE/save/ -type f | wc -l
8963
Je pensais qu'il se contentait de regarder la date modif uniquement, non ?
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.
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.
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.
$ find /media/KEYSAVE/save/ -type f | wc -l
8963
Je pensais qu'il se contentait de regarder la date modif uniquement, non ?
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.
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.
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.
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?
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?
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 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).
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).
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).
rsync -axh --delete --progress --modify-window=2
rsync -axh --delete --progress --modify-window=2
rsync -axh --delete --progress --modify-window=2
Ça marche le "atime" avec le FAT32 ?
Ça marche le "atime" avec le FAT32 ?
Ça marche le "atime" avec le FAT32 ?
Ça marche le "atime" avec le FAT32 ?
Oui. C'est le ctime qui n'a pas d'équivalent en fat.
Ça marche le "atime" avec le FAT32 ?
Oui. C'est le ctime qui n'a pas d'équivalent en fat.
Ça marche le "atime" avec le FAT32 ?
Oui. C'est le ctime qui n'a pas d'équivalent en fat.
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.
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.
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).
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).
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).