[testing] rsync et freeze système et usage tmp

hello,

2013/1/21 Sylvain L. Sauvage <Sylvain.L.Sauvage@free.fr>:

’jour,

Le lundi 21 janvier 2013 à 09:33:17, noway private a écrit :

[…]
> rsync -avx --temp-dir=/tmp --progress --delete $exclud
> $HOME $DEVICE

perso j’enlèverai le temp-dir et y collerai le inplace

Je ne sais pas pourquoi vous voulez tous utiliser --inplace.
--inplace est dangereux, surtout pour une sauvegarde.

En effet oui, pendant un certain moment (le temps de synchro) pas de
consistance cas d'échec ceci dit les disques sont en local.. l'idée
était d'outre passer le répertoire /tmp.

Il y a trois comportements :

— --temp-dir : les fichiers sont envoyés dans ce répertoire puis
déplacés dans la distination finale.
C’est une très mauvaise idée quand le répertoire temporaire
n’est pas sur la même partition que la destination : il y a
une copie en plus.
C’est utile si la destination n’a pas la place pour le plus
gros fichier à envoyer (puisque dans le cas normal, il y a
deux copies du fichier pendant le transfert) ;

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 ?

— --inplace : les fichiers sont envoyés directement dans la
destination finale.
C’est une très mauvaise idée si le transfert est interrompu :
le fichier est alors dans un état intermédiaire donc avec de
fortes chances de corruption.
C’est rarement utile (réduit un peu les E/S disque).

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.

— ni l’un ni l’autre, le comportement par défaut : les fichiers
sont envoyés dans la destination finale mais sous un nom
temporaire et remplaceront l’ancienne version une fois l’envoi
terminé (pour chaque fichier ; on n’attend pas la fin de tous
les envois, sauf avec --delay-updates).

oui oui on est d'accord comportement par défaut de rsync...

Tout ça est dans le manuel…

encore faut il savoir l'appliquer :)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAH_2pOWmK_n9OoRzo=YOdvZ852NRqHESF0_Mb2Xx9fPhRSBBTw@mail.gmail.com

[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 e nvie 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ère ment 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 se uls fichiers
modifiés.

Donc, puisque c = δ, si (a + b) > (α + β + γ), --te mp-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 p as
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

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/201301211150.40088.Sylvain.L.Sauvage@free.fr

Salut,

Suite de mes aventures avec rsync.
J'ai finalement retiré l'option --temp_dir et ça semble mieux se passer.
De plus ça augmente fortement les débits sur mon disque en USB3.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130210214543.eb309138ca303b2dcce9a578@neuf.fr