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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
