Hi, I'm currently reencrypting my (hardware) RAID setup, which is quite big (12 TB) in order to change the cipher from aes-xts-plain to aes-xts-plain64. While playing around with various options, I found out that a block size of 64 MB and the use of direct I/O results in the highest speed for me. Now, I admit that at least the "optimal" block size depends very much on your setup and the caches and/or buffers involved. However I would argue that enabling direct I/O should be faster on most systems considering that usual block devices are probably quite big - at least compared to "normal" files and reencrypting the device is a purely consecutive process. Running some tests I could confirm my assumption. In my case where I've got a hardware RAID with read ahead enabled, it makes at least a difference of about 10%. Is there a reason why direct I/O is not enabled by default? Maybe I'm missing something obvious here? Personally I think that 10% can be quite much, especially when the process takes 24 hours and more. That said I think the bigger influence is the choice of the right block size. By choosing the right block size I could double the speed. As already said above I think it probably is quite hard to get this one right automatically for each and everyone, because it depends upon various caches involved. From a theoretical stand point it probably should be about half the size of the smallest cache involved. I'm not sure whether it makes any sense (or is even possible) to probe for these things, but considering the speed enhancement of - at least in my case - 100%, there should probably be something done about it. Now, before implementing any of this, I would like to know whether you've got similar and/or even contradicting experiences and whether there are specific reasons for the default values of the options mentioned above. Maybe I'm just generalizing too much here when trying to come up with some conclusions based on my hardware. Best regards, Karol Babioch
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt