Re: [testing] rsync et freeze système et usage tmp
[Pas de CC perso, merci.]
Le lundi 21 janvier 2013 à 10:15:10, noway private a écrit :
> hello,
Re’,
>[…]
> > --inplace est dangereux, surtout pour une sauvegarde.
>
> En effet oui, pendant un certain moment (le temps de synchro)
> pas de consistance
En français, on dit _cohérence_. Sinon, ton discours a la
« consistance du yahourt », autrement dit la cohérence d’une
chanson yéyé ;o)
> cas d'échec ceci dit les disques sont en
> local.. l'idée était d'outre passer le répertoire /tmp.
Ben justement, il suffit pour cela de ne pas utiliser l’option
--temp-dir. Tout simplement. Non ?
C’est pour cela que j’ai du mal à comprendre cette envie de --
inplace. Et vu que tu l’as proposée deux fois, j’avais cru que
tu n’étais pas le seul à l’avoir proposée ; d’où mon urgence à
stopper l’épidémie ;o)
>[…]
> Je lui ai proposé, en attendant, d'enlever ce paramètre pour
> le remplacer par inplace pour éviter de gonfler le /tmp,
> sinon pour garantir la consistance remplacer le tmp par le
> répertoire final, comportement par défaut d'ailleurs il me
> semble ?
Pas tout à fait : si --temp-dir = destination, alors les
fichiers temporaires sont placés dans la destination, à la
racine locale. P.ex., si un des fichiers à déplacer est
ici/truc/machin vers là-bas/, le fichier temporaire sera placé
en là-bas/.truc-machin-xxx. Sans --temp-dir, il est placé en là-
bas/truc/.machin-xxx.
Niveau E/S, c’est important si la destination est sur
plusieurs partitions (rare ?).
>[…]
> Oui pas de consistance ceci dit tout est en local (disque
> usb, firewire...) pas en réseau ça réduit légèrement les
> risques, l'idée était en fait de faire une première synchro
> et d'enlever ce paramètre car non consistant...mais évitant
> les io.
Hmm, voyons les cas, en supposant temp-dir séparé de la source
et de la destination :
— --temp-dir :
1. transfert des fichiers vers temp-dir pour y créer des des
fichiers complets (et comme ils n’y sont pas du tout, ils
sont transférés complètement) ;
2. écrasement des fichiers dans la destination (équivalent à
un cp) ;
— --inplace :
1. transfert partiel des fichiers vers la destination, seuls
les bouts qui changent sont transférés et écrits ;
— sans ces options :
1. transfert partiel des fichiers vers la destination pour y
créer des fichiers complets (avec des bouts des originaux ;
donc transfert disque vers mémoire de ces bouts avant de les
renvoyer accompagnés des bouts modifiés) ;
2. écrasement des fichiers dans la destination (équivalent à
un mv).
Clairement, le cas --temp-dir est le pire, avec transfert et
copie complets.
« Sans option » est le suivant, avec transfert partiel mais
création complète de la nouvelle version.
Enfin, --inplace qui transfert et écrit partiellement les
fichiers.
Donc, oui, --inplace semble plus économe en E/S. Mais il faut
des modifications qui le permettent (fichiers seulement
augmentés à la fin (append) ou par morceaux (remplacment d’un
bloc par un bloc de même taille) et des E/S disque lentes pour
que ce soit efficace et contrebalancer les risques.
Hmm, je crois que je vois un intérêt du --temp-dir en local :
il pourrait être plus rapide si les E/S sur la destination sont
vraiment lents.
En local, sans --temp-dir, le fichier final est :
a. partiellement lu de l’origine (E/S supposées rapides) ;
b. partiellement lu de la destination (E/S supposées lentes) ;
c. totalement écrit sur la destination.
Toujours en local, avec --temp-dir, le fichier final est :
α. totalement lu de l’origine (rapide) ;
β. totalement écrit dans temp-dir (rapide) ;
γ. totalement lu de temp-dir (rapide) ;
δ. totalement écrit dans la destination (lent).
En clair, ça force à ne rien lire dans la destination. Côté
destination, c’est l’équivalent d’un cp des seuls fichiers
modifiés.
Donc, puisque c = δ, si (a + b) > (α + β + γ), --temp-dir est
intéressant. Ce qui peut être facilement le cas si temp-dir est
en mémoire. (Et sans compter les optimisations que le noyau peut
faire avec son cache et entre son cache et mmap…)
Mouaif, dans ce cas-là, je sais pas si je ne préférerais pas
utiliser vraiment le vrai cp (avec rsync juste pour créer la
liste des fichiers à transférer)…
Mais bon, je digresse. (Grèce !)
>[…]
> > Tout ça est dans le manuel…
>
> encore faut il savoir l'appliquer :)
Ok, ceci explique cela ;oP
--
Sylvain Sauvage
Reply to: