rsync – copie simultanée sur deux disques

stylik · Le 19/11/2024, à 09:54

bonjour,

j'ai un disque data que je souhaite copier simultanément sur deux disques de sauvegarde vierges avec rsync

j'hésite à utiliser un chaînage type && car la première commande doit être terminée pour que la deuxième s'exécute ce qui ne me ferait pas gagner de temps

rsync -ai DO/ DA/ && rsync -ai DA/ DB/

le DO est volumineux, environ 900 Go, soit une semaine de synchronisation non-stop …
je suppose que le facteur limitant est le faible cache L1 du cpu – 128 ko – , un goulot d'étranglement pour l'adressage.

il faudrait que rsync envoie le même contenu simultanément sur deux sorties
mais est-ce possible ?

Watael · Le 19/11/2024, à 10:16

salut,

&& exécute la seconde commande SI la première a réussi, alors que
& exécute la seconde commande sans attendre que la première soit terminée.

pourquoi DO->DA, puis DA->DB, et pas DO->DA et DO->DB ?
la seconde copie ne dépend alors plus de la première, qui pourrait être mise en arrière plan...

stylik · Le 19/11/2024, à 10:46

entendu, merci pour les conseils
je vais essayer tout ça

stylik · Le 19/11/2024, à 10:52

une petite question tout de même,
que signifie « en arrière plan » ?

Watael · Le 19/11/2024, à 11:17

le shell exécute la tâche dans un sous-shell, et n'attends pas qu'elle se finisse pour exécuter la tâche suivante.

stylik · Le 19/11/2024, à 11:20

je précise ma petite question,
en quoi cela améliore-t-il les performances de rsync de passer la première commande en arrière plan ?
et aussi, comment scinder l'exécution de deux commandes situées sur une même ligne ?

geole · Le 19/11/2024, à 11:34

Bonjour.
Tu devrais chercher pourquoi cela met une semaine. La première fois, une journée je veux bien....
Pourquoi dis-tu non-stop? Si au bout d'une journée , tu stoppes et que tu relances, ce qui a été transféré ne le sera plus....
Fais-tu intervenir le réseau???

Lorsque tu lances deux commandes simultanément grâce au caractère & Seul le déroulement de l'une est visible à l'écran (La première La seconde). L'autre n'est pas visible, tu seras juste informé de sa terminaison.
Dans l'ensemble, la lecture est plus performante que l'écriture. Donc deux écritures simultanées font gagner du temps.

Dernière modification par geole (Le 19/11/2024, à 17:28)

stylik · Le 19/11/2024, à 12:59

b'en écoute je suis ravi d'apprendre tout ça.
parce que je ne m'y connais pas beaucoup en commandes, beaucoup moins que ce que j'aimerais en tout cas, par manque de temps bien sûr
ce n'est pas faute de m'en donner les moyens mais je pars de loin et … la route est longue.
J'apprends par petit bout, un peu devant le mur à chaque fois
C'est le cas en ce moment. J'ai un disque data à remplacer parce qu'il est bientôt saturé
j'anticipe parce que l'opération qui ne peut se faire rapidement ne pourra se faire au dernier moment
donc j'ai un peu le temps de travailler ma commande pour essayer de gagner du temps de synchronisation
le challenge des prochains jours c'est de trouver comment synchroniser DO sur deux DA en même temps

Si je n'ai pas la solution, ce sera au forceps … les disques un à un, 24/24 comme je disais pour parler de ce qui s'est déjà passé
bien sûr je me suis demandé d'où venait le problème
franchement j'ai séché, par exemple quand j'ai constaté un débit de 2,8 Miops pendant 14 heure 10 en USB2 (alors que le débit théorique est 60 Mops) pour transférer un DO de 144,5 Go sur un disque externe USB3
c'est pourtant du direct, de DO à DA d'un syf à l'autre en ligne droite (y a juste un sata et un usb à traverser), pas de réseau

je ne vois que le cache du cpu comme goulot d'étranglement (parce qu'il faut bien se trouver une réponse, un peu comme pour la religion), le cache étant la mémoire du cpu, donc une interface, plus il est petit, plus la communication du cpu avec les contrôleurs pour l'adressage des blocs tournera au ralenti. C'est totalement empirique comme explication parce que je n'ai pas le temps ni les moyens d'investiguer pour trouver d'autre chose. Donc je fais avec cette explication. Je pourrais vérifier en utilisant une configuration plus performante, dernier cri testostéronée en cache, mais bon … ça n'est pas ma tasse de thé de changer de configuration à la volée. Sans compter que ce n'est pas gagné d'avance.
Donc au final je procède DO par DO et je note tous les chrono. Un mauvais moment à passer. Une fois que c'est fait, basta.

J'arrête ici ma prose pour revenir à ta réponse, que je reformule à ma manière
parce que je ne crois pas avoir bien saisi la logique entre tes deux prépositions

« la lecture est plus performante que l'écriture. Donc deux écritures simultanées font gagner du temps.»

En passant deux commandes avec &, il n'y a

qu'une lecture (DO) pour deux écritures (DA + DB) simultanées

et qu'un verbose (DO +> DA)

Ce qui fait gagner du temps par rapport à un chaînage de commandes &&

Est-ce bien ça ?

geole · Le 19/11/2024, à 13:24

stylik a écrit :

franchement j'ai séché, par exemple quand j'ai constaté un débit de 2,8 Miops pendant 14 heure 10 en USB2 (alors que le débit théorique est 60 Mops) pour transférer un DO de 144,5 Go sur un disque externe USB3

J'ai rencontré un problème semblable. C'était avec un disque interne et en lecture
Il lisait tranquillement à 150 Mo/s. Sans que je comprenne le pourquoi, il a chuté à 2 Mo/s. Et, du coup, il annonçait plus de quatre jours pour terminer.

a@et:~/Bureau/SDB$ sudo ddrescue -f -n -b$((512*$M)) /dev/$DSKin /dev/$DSKout $Suivi
GNU ddrescue 1.27
Press Ctrl-C to interrupt
     ipos:    2840 GB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    2840 GB, non-scraped:        0 B,  average rate:    122 MB/s
non-tried:    1160 GB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    2840 GB,   bad areas:        0,        run time:  6h 25m 50s
pct rescued:   70.99%, read errors:        0,  remaining time:  4d 13h 22m
                              time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)^C
  Interrupted by user

J'ai tué, et relancé. Pareil
J'ai tué, attendu une heure, et relancé. Pareil
J'ai arrêté l'ordinateur et relancé. Le débit redevient correct.

a@et:~/Bureau/SDB$ sudo ddrescue -f -n -b$((512*$M)) /dev/$DSKin /dev/$DSKout $Suivi
[sudo] Mot de passe de a : 
GNU ddrescue 1.27
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 2840 GB, tried: 0 B, bad-sector: 0 B, bad areas: 0

Current status
     ipos:    4000 GB, non-trimmed:        0 B,  current rate:  16146 kB/s
     opos:    4000 GB, non-scraped:        0 B,  average rate:  50204 kB/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    4000 GB,   bad areas:        0,        run time:  6h 25m  8s
pct rescued:  100.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (forwards)
Finished

Les quatre jours et demi sont devenus six heures et demie. Je soupçonne une déactivation du cache.

NOTA. Si tu lances deux process simultanément, ils liront deux fois chaque secteur. Par moment cela peut être contre-productif.

Dernière modification par geole (Le 19/11/2024, à 13:26)

stylik · Le 19/11/2024, à 15:39

je glane des informations à l'improviste pour circonscrire le problème
par exemple hdparm mesure le « Timing buffered disk reads »
les scores sont très hétérogènes

SSD sur SATA2 (max théorique 300 Mops)
/dev/sda: 312 MB in 3.52 seconds = 88.61 MB/sec

disque externe USB3 branché sur USB2 (max théorique 60 Mops)
/dev/sdc: 2 MB in 6.45 seconds = 317.55 kB/sec
/dev/sdc1: 60 MB in 3.03 seconds = 19.78 MB/sec

en conditions réelles les performances des contrôleurs sont très décevantes avec toute une chaîne d'obstacles (changement de syf, taille de fichiers variable, interfaces matérielles différentes, éventuel chiffrement) qui mis bout à bout dégradent les débits
Et si en plus le cache fait des siennes (taille insuffisante ou dysfonctionnement) alors c'est la fin car je ne vois pas comment réparer un cache qui se désactive. Les voies de l'électronique sont impénétrables en ce qui me concerne.

Allez, je retourne à ma commande …

Watael · Le 19/11/2024, à 16:12

geole a écrit :

Lorsque tu lances deux commandes simultanément grâce au caractère & Seul le déroulement de l'une est visible à l'écran (La première).

la deuxième ! la première, elle, est en arrière-plan, mais sa sortie standard s'intercale dans l'affichage courant :

~ $ maFonc1() { for i in {a..d}; do echo $i; sleep .5; done;}
~ $ maFonc2() { for y in {1..4}; do echo $y; sleep .5; done;}
~ $ maFonc1 & maFonc2
[1] 659571
1
a
2
b
3
c
4
d
[1]+  Fini                    maFonc1
~ $

Dernière modification par Watael (Le 19/11/2024, à 16:14)

stylik · Le 20/11/2024, à 18:05

Pour illustrer qu'une différence de système de fichier (syf) entre DO et DA pourrait expliquer les 2.8 Miops de débit durant la sauvegarde d'un disque Sata vers un disque externe usb, il suffit de regarder la différence d'Inœuds utilisés par les deux syf (DO en ext4 et DA en fuseblk/ntfs) pour une même quantité de données (651G) : 233M contre 3,1G

$ df -Th /dev/sdc1
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur 
/dev/sdc1        ext4   3,6T    651G  3,0T  18% /media/sdc1
$ df -Th /dev/sdd2
Sys. de fichiers Type    Taille Utilisé Dispo Uti% Monté sur 
/dev/sdd2        fuseblk   3,7T    651G  3,1T  18% /media/TOSHIBA EXT 

$ df -Tih /dev/sdc1 
Sys. de fichiers Type Inœuds IUtil. ILibre IUti% Monté sur 
/dev/sdc1        ext4   233M   727K   233M    1% /media/sdc1
$ df -Tih /dev/sdd2 
Sys. de fichiers Type    Inœuds IUtil. ILibre IUti% Monté sur 
/dev/sdd2        fuseblk   3,1G   719K   3,1G    1% /media/TOSHIBA EXT

forcément le cpu ou le contrôleur doivent en prendre plein la gueule, si je puis m'exprimer ainsi.
mais à confirmer

geole · Le 20/11/2024, à 19:34

Bonsoir
Je suis très sceptique pour l'explication par les inoeuds car avec un autre pilote ntfs

df -Tihtntfs3
Sys. de fichiers Type  Inœuds IUtil. ILibre IUti% Monté sur
/dev/sda7        ntfs3      0      0      0     - /media/W21H2b
/dev/sda4        ntfs3      0      0      0     - /media/W21H2a
/dev/sdd4        ntfs3      0      0      0     - /media/a/W21H2b-SAVE
/dev/sdd3        ntfs3      0      0      0     - /media/a/W21H2a-SAVE
a@p:~$]

stylik · Le 29/11/2024, à 21:41

Figure-toi que j'obtiens aussi des inœuds à 0 avec df -ti pour une partition sdb2 (DO) formatée en reiserfs.
Et ça me surprend car reiserfs est 'linux natif'.

$ df -Ti /dev/sdb2 											DO
Sys. de fichiers Type     Inœuds IUtil. ILibre IUti% Monté sur 
/dev/sdb2        reiserfs      0      0      0     - /media/sdb2

Le résultat pour la partition sdc2 réceptrice (DA) formatée en ext4 est :

$ df -Ti /dev/sdc2 												DA
Sys. de fichiers Type    Inœuds IUtil.    ILibre IUti% Monté sur 
/dev/sdc2        ext4 237633536 803049 236830487    1% /media/sdc2

C'est conforme au résultat précédent (sdc1), pour les mêmes données avec quelques giga en plus.

Question débit, la synchronisation sata sdb2 vers sata sdc2 a été nettement plus véloce que sata sdc1 vers usb Toshiba Ext, avec environ 20 mops de moyenne et une pointe à plus de 40 mpos (grosses archives).

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/11/2024, à 09:54

rsync – copie simultanée sur deux disques

#2 Le 19/11/2024, à 10:16

Re : rsync – copie simultanée sur deux disques

#3 Le 19/11/2024, à 10:46

Re : rsync – copie simultanée sur deux disques

#4 Le 19/11/2024, à 10:52

Re : rsync – copie simultanée sur deux disques

#5 Le 19/11/2024, à 11:17

Re : rsync – copie simultanée sur deux disques

#6 Le 19/11/2024, à 11:20

Re : rsync – copie simultanée sur deux disques

#7 Le 19/11/2024, à 11:34

Re : rsync – copie simultanée sur deux disques

#8 Le 19/11/2024, à 12:59

Re : rsync – copie simultanée sur deux disques

#9 Le 19/11/2024, à 13:24

Re : rsync – copie simultanée sur deux disques

#10 Le 19/11/2024, à 15:39

Re : rsync – copie simultanée sur deux disques

#11 Le 19/11/2024, à 16:12

Re : rsync – copie simultanée sur deux disques

#12 Le 20/11/2024, à 18:05

Re : rsync – copie simultanée sur deux disques

#13 Le 20/11/2024, à 19:34

Re : rsync – copie simultanée sur deux disques

#14 Le 29/11/2024, à 21:41

Re : rsync – copie simultanée sur deux disques

Pied de page des forums