Pourquoi rsync se fourche-t-il? Et pourquoi un tel processus fourchu est presque un peu inactif (comme vu dans iotop)?

Cela fait référence à la question énoncée ici et j'en fais également l'expérience.

Dans l'un de mes serveurs, j'ai exécuté un rsync, pour sauvegarder un énorme répertoire (taille supérieure à 300 Go) sur un disque différent, monté sur la même machine. Le répertoire en cours de synchronisation contient des milliers de répertoires et de fichiers. J'ai émis une seule commande rsync, avec «nohup», puis je l'ai poussée en arrière-plan à l'aide de la commande «&». La commande complète donnée sur le shell bash distant (à l'aide de putty) était:

nohup rsync -avh /some/local/dir /backup/ >> /opt/rsync.dec22.log &

Ensuite, juste pour vérifier à quelle vitesse les données étaient copiées, j'ai utilisé la commande 'iotop' et j'ai découvert qu'il y avait 3 rsync fonctionnant avec les mêmes paramètres. Lors de la recherche, j'ai trouvé le lien ci-dessus qui dit que c'est normal.

Mais en faisant un iotop pour surveiller uniquement ceux-ci et les seuls processus rsync en cours d'exécution sur le système, je vois qu'un processus lit des fichiers, un les écrit, mais un est inactif. Le comportement semble être bon, car un processus ne fait qu'une chose à la fois, mais que fait le 3e processus (vu comme le milieu dans l'image ci-dessous)?

La commande iotop que j'avais utilisée était:

iotop -p22250 -p22251 -p22252

Voici la capture d'écran de la sortie de la commande iotop:

Sortie de la commande iotop montrant 3 processus rsync

Je pose cette question car j'utilise beaucoup rsync et je veux comprendre son comportement pour un bénéfice à long terme. J'ai même lu le manuel, mais il ne dit rien de la fourche.

linux rsync command

— Gautam Somani
source

rsync est un programme conçu pour être un client et un serveur. Le serveur lit et le client écrit. Imaginez qu'au lieu d'un seul ordinateur, vous aviez des ordinateurs sur le réseau, je suis sûr que c'est beaucoup plus clair si vous pensez de cette façon.

Ensuite, il y a le contrôleur. Comme les opérations d'E / S ont tendance à comporter un certain degré de risque, un problème d'E / S ne devrait pas provoquer un blocage total ou un crash. Ainsi, il crée une fourchette pour chaque connexion et se trouve en arrière-plan.

— Grincheux
source

Merci pour la connaissance. Je le comprends du point de vue d'ordinateurs distincts sur le réseau, chaque ordinateur effectuant une partie du travail en synchronisation. Mais pouvez-vous également me référer à la documentation sur le comportement où je peux lire plus de choses sur rsync et sur le concept? Vous souhaitez également savoir comment les données lues sont transmises par le processus de lecture au processus qui écrit? Le concept d'IPC est-il utilisé?

— Gautam Somani

@GautamSomani La page officielle rsync sera votre meilleure source pour cela. rsync.samba.org De plus, la façon dont cela fonctionne est disponible ici: rsync.samba.org/how-rsync-works.html Si vous voulez encore plus de détails, vous devrez probablement fouiller dans la source.

— Grumpy

L'auteur d'origine lance rsync localement. Il ne se connecte pas à rsyncd donc il n'y a aucun moyen que le démon bifurque son enfant. Et il n'y a pas de connexions réseau. Il reste donc à savoir pourquoi rsync forks lorsqu'il est exécuté localement. La réponse est trompeuse et erronée.

— drookie

@drookie Peu importe qu'il soit local ou sur réseau. Cela fonctionne de la même manière. Il explique également ce comportement dans le document officiel que j'ai lié juste au-dessus de votre commentaire, qui dit également "soit dans un transfert local, via un shell distant ou via une prise réseau".

— Grumpy