On 11/23/2012 05:12 AM, Karol Babioch wrote: > 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. But unfortunately your assumption is not correct. Not only direct hw is used, many times you are running container from file (namely for virtual machines). I have no problem with changing defaults but I selected current defaults because of testing quite a lot of systems. But everything is configurable (and you can even restart reencryption with changed options.) > 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%. Differences can be even 30-40% but both directions, depends on system. (For different block sizes even more.) So not only direct io, also block size and sometimes enabling fsync helps too. > 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. Just few use cases I tried - notebooks with SSD or rotational disks - high speed PCIe SSD array - direct rotational disk - MD arrays of rotational disks - external storage (with FC multipath betwen it) - iSCSI - VM with file backend (VMware and KVM) ... Try it, you will see that common default doesn't work for some of these. Anyway, defaults can be changed, we can add some heuristic or benchmark but I would like to see that tool tested more first. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
