Overhead de -a flag dans la commande cp

Disons que nous avons un service de sauvegarde personnalisé qui suit l’ approche rsync suggérée par Mike Rubel . Pour effectuer des rotations de sauvegarde, cette commande cp doit être utilisée:

 cp -al source target

Ayant cela, j’essaie de faire pivoter un répertoire de 35 Go qui a beaucoup de petits fichiers (~ 5 Ko-200 Ko), c’est-à-dire un très grand répertoire d’arborescence. Le problème est que cela dure au moins cinq heures. Cela me semble beaucoup, surtout en utilisant l’option -l .

Est-ce normal ce comportement avec les disques SATA? L’ -al peut-elle provoquer une surcharge supplémentaire dans la commande cp qui entraîne ce délai?

Merci!

Si les fichiers ont une taille d’environ deux gigaoctets, je pense que c’est très lent. Si les fichiers ont tous une taille d’environ 200 octets, je pense que c’est rapide. Eh bien, je ne sais pas vraiment combien les fichiers doivent être petits avant de penser que cette vitesse est rapide, mais s’ils sont tous minuscules, votre disque passera le plus clair de son temps à chercher, lire des métadonnées, écrire des métadonnées, revues engageantes, etc.

Mais cela semble frustrant, de toute façon.

Quelques idées viennent immédiatement à l’esprit:

Vous pouvez désactiver les a_time disponibilité pour le système de fichiers spécifique en question, si vous n’utilisez pas a_time pour quoi que ce soit. (Ajoutez l’ noatime mount(8) à votre fstab(5) .) Cela éviterait une énorme quantité d’écritures éparses sur le côté «lecture» de votre opération de copie. Cela pourrait éliminer un petit pourcentage de temps. 5%? dix%? Peut-être plus? L’avantage est qu’il faut quelques secondes pour utiliser mount(8) -oremount,noatime et ensuite découvrir. 🙂
~~Vous pouvez utiliser des liens durs au lieu de copies~~ . ( cp(1) mentionne une option de ligne de commande -l pour utiliser des liens – je dois admettre que je n’ai jamais essayé, j’ai toujours fait mes liens avec ln(1) , mais pour des centaines de milliers de fichiers sonores Donc, essayez -l pour cp(1) et rapportez. 🙂 L’avantage d’utiliser des liens physiques est (a) l’espace disque enregistré (b) la bande passante du disque enregistrée – seules les métadonnées sont lues / écrites, ce qui peut être des milliers de fois plus rapide. Ce n’est peut-être pas l’outil que vous voulez, mais cela dépend vraiment de la manière dont vos applications modifient les données pendant que l’opération de sauvegarde est en cours d’exécution.
Vous pourriez trouver un remplacement plus intelligent pour le tout. rsync est un excellent outil, mais pas extrêmement shiny. git(1) peut être un outil plus intelligent pour votre tâche. Sans faire de copie du tout, cela pourrait aller beaucoup plus vite.
Vous pouvez utiliser certaines astuces de périphérique de bloc intelligentes: par exemple, les instantanés LVM , pour permettre à votre opération de sauvegarde de se dérouler en parallèle avec l’utilisation, et supprimer l’instantané lorsque la sauvegarde est effectuée. Cela devrait être beaucoup plus rapide si vos données ne changent pas beaucoup. S’il y a beaucoup de perte, cela pourrait être légèrement meilleur. Mais laissez votre rsync démarrer à proximité immédiate plutôt que de l’autre côté d’une fenêtre de cinq heures.