rsyncの片側をそんなに忙しくしているのは何ですか？
私のLANには、他の人のバックアップサーバーとして機能するDebianマシンがあります。4つのHDDがソフトウェアRAID 5 mdデバイスに結合されており、そのLVMとそのbtrfs上にあります。バックアップはrsyncを使用して行われ、大きなファイルシステムの場合は1時間以上かかります。長い間、私はこれについてできることはほとんどないと思っていました。 しかし最近、転送の両端でHDDアクティビティが大きく異なることに気付きました。Gentooを実行していて、ほとんどがext4を使用している送信側には、ディスクIOがほとんどありませんでしたが、受信側は常にビジーでした。ほとんどのデータは転送間で変化しないので、メタデータの読み取りはデータの大部分を占めるはずだと思います。しかし、btrfsでiノードを読み取ることがext4で同じことを行うよりも多くの作業であるとしたら、私は本当に驚きます。 iotop 受信側で約1〜4 MB /秒のディスク読み取りを確認しましたが、送信側ではたまに0.5 MB /秒のバーストしかありませんでした。 私の質問は、誰かがここで何が起こっているのか説明できますか？できれば、問題を回避する方法を示してください。 おそらく、私が使用できるいくつかのbtrfsチューニングフラグ、または類似したものがあります。バックアップサーバーにスナップショット機能を備えたFSが必要です。FreeBSDとZFSを使用しようとすると、すぐにFSの一貫性が失われるため、現時点ではbtrfsに代わるものはほとんどありません。したがって、ext4またはzfsを使用するように指示する回答は、賛成票を受け取る可能性がありますが、チェックマークは受け取りません。 cjmからの要求に応じて、使用中の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フラグが含まれているため、一部のファイルに実際に違いがない限り、書き込みは必要ありません。私は、に応じてこの情報を追加した答えによって、カイル・ジョーンズ。