rsyncの片側をそんなに忙しい状態に保つのはなぜですか?

rsyncの片側をそんなに忙しい状態に保つのはなぜですか?

私のLANには、他のコンピュータのバックアップサーバーとして機能するDebianコンピュータがあります。 4つのHDDがソフトウェアRAID 5 mdデバイスにグループ化されており、そのデバイスとそのbtrfsにLVMがあります。バックアップはrsyncを使用して行われ、大容量ファイルシステムでは1時間以上かかりました。長い間、私はそれについて私ができることが何もないと思いました。

しかし、最近ハードドライブの活動が検出されました。非常に転送の両端が異なります。送信者がGentooを実行し、ほとんどext4を使用し、ディスクIOがほとんどない間、受信者は常に使用されています。ほとんどのデータは転送間で変更されないため、メタデータの読み取りがデータの大部分を占める必要があると思います。しかし、btrfsでinodeを読むことはext4でinodeを読むよりも多くの作業が必要な場合は非常に驚くでしょう。

iotop受信側のディスク読み取り速度が約1-4MB/sであるのに対し、送信側では間欠的に0.5MB/sのバーストのみ経験することを確認しました。

私の質問は、何が起こっているのかを説明できる人がいますか?この問題を解決する方法についていくつかのガイドラインを提供することをお勧めします。

おそらくbtrfsチューニングフラグなどを使用できます。バックアップサーバーにスナップショット機能を備えたFSが必要であり、FreeBSDとZFSを使用しようとするとFSの不整合が発生するため、現在ではbtrfsの代替手段が見つかりません。したがって、ext4またはzfsを使用するように回答することは賛成票を受け取りますが、チェックマークは受け取らない可能性があります。


要件に応じて Rsync オプションを使用します。ウェストジェム:

--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

-f特定のファイルを省略するいくつかの規則もあります。


btrfsのマウントオプションはmount次のように報告されます。

rw,nosuid,noexec,noatime,nospace_cache

特にこれにはnoatimeフラグが含まれているため、一部のファイルが実際に異なる場合を除き、書き込みを含めないでください。これに応答してこの情報を追加します。回答渡すカイル・ジョーンズ

答え1

1つの可能な答えは、リモートファイルシステムがデフォルトで「atime」オプションを使用してマウントされることです。リモート側のI / O増幅は、リモートrsyncでアクセスされるすべてのエントリのアクセス時間の書き込みとRAID 5で発生する書き込みペナルティで説明できます(コンピューティングパリティは、RAIDディスクのいずれかに書き込む前にすべてのRAIDディスクを読み取ることを意味します。 )。

私が正しい場合は、「noatime」オプションを使用してリモートファイルシステムをマウントすると、作業を高速化できます。

答え2

--fake-super オプションが疑われます。これは、rsyncに各ファイルの拡張属性にすべてのメタデータ情報を保存するように指示します。これらのプロパティにアクセスするのが遅いようです。 --fake-superなしでルートディレクトリでrsyncテストを実行します。属性が一致しないため、同じバックアップを再利用できません。

答え3

--xattrs/-Xアップストリームコミット(まだリリースされていません)がDebianのrsync 3.1.2-2に統合される前は非常に遅かったです。

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799143#20

https://bugzilla.samba.org/show_bug.cgi?id=5324

関連情報