Re: [dm-crypt] poor mysqldump performance

[Tracy Reed <treed@ultraviolet.org>]

On Fri, Feb 24, 2012 at 09:05:29PM +0100, Arno Wagner spake thusly:
> Blocks used in dm-crypt are allways 512 Bytes in size, hence no extra reads
> or writes compared to non-encrypted disks should ever be required. 

Ok, so there goes that theory.

> Please to not. ECB is massively insecure. And it will not result in reading
> less data. Well, you can do it as an experiement, but please do not use it
> when it has to be secure.

I already did a test with it and as you correctly expected, it made no
difference. We certainly won't be deploying ECB. I am aware of the same
plaintext security issues with it.

> It should not. But if you notice a difference, it may be interesting to see
> what it is.

I found no difference.

> There is also another possible factor that may make a larger or smaller
> difference: If I remember correctly, you said the dump was going to the same
> disk, but from different partitions for encrypted and non-encrypted. This may
> influence speeds. First, head seeks are dependend on seek distance. The

You remember incorrectly: The dump is being done using mysqldump on a remote
machine. So it is going over the network and writing to totally different
disks.

> regions have different data density. My observation is that disk linear
> throughput drops to less than half towards the end of many disks.  And third,
> you may have a different fragmentation or data placement situation or
> filesystem parameter on both source disks.

This is a very good observation and could be part of the problem here. I have
been using different logical volumes on the same disk. I will try using the
same LV mapped with dm-crypt vs no crypto and see if that helps.

Thanks!

-- 
Tracy Reed