I've got a debian machine in my lan serving as a backup server for the others. It has four HDDs combined into a software RAID 5 md device, on that an lvm, and on that a btrfs. Backups are made using rsync, and for a large filesystem take over an hour. For a long time I had thought there would be little I could do about this.
Recently, however, I noticed that the HDD activity was very different on both ends of the transfer. While the sending side, running Gentoo and mostly using ext4, had hardly any disk IO at all, the receiving side was constantly busy. As most data wouldn't change between transfers, I believe that metadata reads should make up the bulk of the data. But I'd be really surprised if reading inodes in btrfs is so much work than doing the same in ext4.
iotop confirmed disk reads of about 1-4 MB/s on the receiving side, whereas the sending side had only the occasional 0.5 MB/s burst.
My question is, can anyone explain what's going on here? Preferrably with some indication how to work around the problem if possible.
Perhaps there is some btrfs tuning flag I could use, or something similar. I need a FS with snapshot capabilities on the backup server, and my attempt to use FreeBSD and ZFS quickly lead to an inconsistent FS, so I see little alternative to btrfs at the moment. Therefore answers telling me to use ext4 or zfs might receive upvotes but no check mark.
Rsync options in use, as requested by 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
As well as a bunch of
-f rules to omit some files.
The mount options of the btrfs are reported by
In particular, this includes the
noatime flag, so there shouldn't be any writing involved unless there actually were differences in some files. I added this information in response to the answer by Kyle Jones.