Hey. Send/receiving the master to the backup has finished just before... and now - not that I wouldn't trust btrfs, the hardware, etc. - I ran a complete diff --recursive --no-dereference over the snapshots on the two disks.
The two btrfs are mounted ro (thus no write IO), there is not really any other IO going on in the system. I basically see a similar up and down as before during writing: This time, only the diff process show up in iotop. Sometimes, I get rates of 280-300 MB/s... for several seconds, sometimes 3-4s... sometimes longer 10-20s,... then it falls down to 30- 40MB/s At the same time I look at which files diff is currently comparing,... and these are all large analog image scans[0] and these are > 800MB (per file). Also the slow downs or speed ups don't happen when diff moves on to a new file... can also be when it still compares the same file for a while. I wouldn't assume that these are highly fragmented, since both filesystems were freshly filled a recently ago, with no much further writes since. And AFAIU, SMR shouldn't kick in here either. I tried to have a short look at how the logical CPUs are utilised at the slow and at the fast phases. There is no exact schema, sometimes (but not always) it looks as if 1-2 cores have some 100% utilisation when it's fast... while when it's slow all cores are at 30-50% But that may also be just coincidence, as I observed the opposite behaviour few times... So don't give too much on this. Why can it sometimes be super fast and the falls back to low speed? Cheers, Chris. [0] yay.. the good old childhood images where they had no digikams... ;)
smime.p7s
Description: S/MIME cryptographic signature
