Re: slowness when cp respectively send/receiving on top of dm-crypt

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

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...
;)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]