J'ai une machine Debian sur mon réseau local servant de serveur de sauvegarde pour les autres. Il dispose de quatre disques durs combinés en un périphérique logiciel RAID 5 md, sur un LVM et sur ce btrfs. Les sauvegardes sont effectuées à l'aide de rsync et, pour un système de fichiers volumineux, prennent plus d'une heure. Pendant longtemps, j'avais pensé que je ne pouvais pas faire grand-chose à ce sujet.
Récemment, cependant, j'ai remarqué que l'activité du disque dur était très différente aux deux extrémités du transfert. Alors que le côté émetteur, exécutant Gentoo et utilisant principalement ext4, n'avait pratiquement pas d'E / S disque, le côté récepteur était constamment occupé. Comme la plupart des données ne changeraient pas entre les transferts, je pense que les lectures de métadonnées devraient constituer la majeure partie des données. Mais je serais vraiment surpris si lire des inodes dans btrfs est autant de travail que de faire la même chose dans ext4.
iotop des lectures de disque confirmées d'environ 1 à 4 Mo / s côté réception, tandis que le côté envoi n'avait que la rafale occasionnelle de 0,5 Mo / s.
Ma question est, quelqu'un peut-il expliquer ce qui se passe ici? De préférence avec quelques indications sur la façon de contourner le problème si possible.
Il y a peut-être un indicateur de réglage btrfs que je pourrais utiliser, ou quelque chose de similaire. J'ai besoin d'un FS avec des capacités d'instantané sur le serveur de sauvegarde, et ma tentative d'utiliser FreeBSD et ZFS conduit rapidement à un FS incohérent, donc je ne vois pas d'alternative aux btrfs pour le moment. Par conséquent, les réponses me disant d'utiliser ext4 ou zfs peuvent recevoir des votes positifs mais aucune coche.
Options Rsync utilisées, comme demandé par cjm :
--rsync-path='rsync --fake-super'
--archive # -rlptgoD
--hard-links # detect and preserve these
--acls
--xattrs
--sparse
--noatime # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable # size suffixes, base 1000
--stats
Ainsi qu'un tas de -frègles pour omettre certains fichiers.
Les options de montage des btrfs sont signalées par mountas
rw,nosuid,noexec,noatime,nospace_cache
En particulier, cela inclut le noatimedrapeau, donc il ne devrait y avoir aucune écriture impliquée à moins qu'il y ait réellement des différences dans certains fichiers. J'ai ajouté ces informations en réponse à la réponse de Kyle Jones .
dtraceousystemtapsavoir où le temps est passé.Réponses:
Une réponse possible est que le système de fichiers distant est monté par défaut avec l'option "atime". Le temps d'accès écrit pour tout ce que le rsync distant accède combiné à la pénalité d'écriture que vous subissez avec RAID 5 (la parité de calcul signifie lire tous les disques RAID avant d'écrire sur l'un d'entre eux) pourrait expliquer le grossissement des E / S du côté distant.
Si j'ai raison, vous pouvez accélérer les choses en montant le système de fichiers distant avec l'option "noatime".
la source
rw,nosuid,noexec,noatime,nospace_cache.Je soupçonne les options --fake-super. Cela indique à rsync de stocker toutes les informations de métadonnées dans des attributs étendus sur chaque fichier. Je soupçonne que l'accès à ces attributs est lent. Essayez un test avec rsync vers une racine sans --fake-super. Vous ne pouvez pas réutiliser la même sauvegarde car les attributs ne correspondent pas.
la source
--xattrs/-Xétait extrêmement lent avant une validation en amont (toujours pas dans une version) qui a été choisie dans rsync 3.1.2-2 de Debian:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799143#20
https://bugzilla.samba.org/show_bug.cgi?id=5324
la source