On 19/03/2021, Maksim Fomin <maxim@xxxxxxxxx> wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > >> On Friday, 19 March 2021 г., 19:09, Johnny Dahlberg >> <svartchimpans@xxxxxxxxx> wrote: >> >>> Hello everyone! >>> >>> Is there anything I am missing here, or anything that you would suggest >>> changing? For example, perhaps I should change "--align-payload 2048" to >>> "--align-payload 4096" (what would that do/improve?), which I've seen a >>> few mentions of? >>> >>> Grateful for any help in clearing this up, or clarifying that my steps >>> are ready to use. It's been a very long research and I'd like to be sure >>> that I am doing everything correctly. >>> >>> With best regards, >>> >>> Johnny > > I think if LVM is partioned on 4k sectors, setting 4k at cryptsetup layer is > not needed - all io requests will be done by lvm with 4k. However, I doubt > there is a way to test this. Btw, I also have multilayer setup with > traditional 512b at plain dm-crypt layer and 4k lvm. Yeah. By default, LUKS (cryptsetup) uses 512 byte sectors. And indeed it's possible to run 4K block size filesystems on top of LVM on top of 512 byte sector LUKS, which simply means that the filesystem will always read/write 8X individual chunks of 512 byte LUKS sectors for each 4K sector FS operation. But LUKS has an inefficient legacy kernel queue design that re-queues and copies queue items multiple times and wastes lots of time and resources grabbing each LUKS chunk, so performance will be better if LUKS is set to 4096 byte sectors simply because this means there's less deep dm-crypt queues. Cloudflare discovered these legacy problems in the dm-crypt code and have upstreamed a semi-reliable patch that gets rid of the slow queues. It has been merged a while ago. But since I don't want to run their early and not yet 100% stable code (some issues with certain hardware or filesystems were found), I decided to instead use the plain old-school dm-crypt queues, and therefore 4K LUKS sectors is a nice queue performance speed improvement compared to 8x512B. Here's the earliest blog post which describes how they doubled the performance of LUKS: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ Here's their discussion about the ongoing work of improving the new "queue-less" dm-crypt flags: https://github.com/cloudflare/linux/issues/1 But the changes aren't mature yet. Picking 4K sector size in LUKS will hopefully reduce the overhead of standard queue mode. Anyway, I hope to hear from someone (perhaps even Milan :) if my storage layer settings in the original message are okay or if they could be improved. Looking forward to doing the OS installation with the correct settings. :-) -- Johnny _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
