[dm-crypt] Reconsidering default options for cryptsetup-reencrypt

[Karol Babioch <karol@babioch.de>]

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

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]