Ok, I let the box run a couple of days with aforementioned settings. I didn’t do a balance yet, neither did I try changing the “commit” time (I feel this is kinda risky, if I understand it correctly).
Either way, my Windows Image changed by 30GB and it is backing this up since almost an hour… This is what iostat -x 5 shows:
Performance is abysmal indeed.
Is this really all down to the SMR nature of my drive, or is the oldish kernel responsible for this horrible performance? I really can’t imagine it would be any better, even if I delayed the “commit” as the process was slow to begin with. At this rate, the speed benefits of BTRFS are totally invalidated.
So I deleted all old Backups now, so I can do a proper free-space rebalance. Still several minutes after the last file transfer I get the following in iotop -o
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
514 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [btrfs-transacti]
513 be/4 root 43.48 K/s 72.47 K/s 0.00 % 99.99 % [btrfs-cleaner]
and iostat shows near 100% utilization:
I guess I should not use SMR drives for the BTRFS/urbackup combination after all? This is obviously without rebalance running.