[dm-crypt] poor mysqldump performance
treed at ultraviolet.org
Fri Feb 24 23:30:20 CET 2012
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
> 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.
More information about the dm-crypt