Sorry for the late reply, just a small followup. What you are saying Milan, is absolutely true, but for misaligned HW Raid setups, a huge block size together with O_DIRECT will bypass the OS'es caching strategy and the controller (knowing the actual layout) has a way better chance of compensating unnecessary IO with it's optimized write back caching (in the linear read-modify-write case of reenrypt). For rather small block sizes (near the size of a RAID stripe) in a misaligned case, such a compensation/elimination of unneeded IO is much harder. So small blocksize, lack of topology information, misalignment -> approx 50% loss in performance (as surveilled by opener) Regards -Sven On Sat, 2012-11-24 at 21:59 +0100, Milan Broz wrote: > On 11/24/2012 06:01 PM, Sven Eschenberg wrote: > > > BTW, what exactly are you referring to, when you talk about 64 MB blocksize? > > Here cryptsetup-reencrypt is in principle simple program, it reads a "block" > and write it back to device with new encryption parameters (and optionally with > some different offset). So block here is meant as an unit which is handled in one > reencryption step. > (But the real atomic unit of encryption is still 512B block of course.) > > There is no requirement this block to be aligned to underlying hw alignment > (but if it is misaligned, the same performance degradation problems apply of course). > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
