On 23/06/2019 12:12, Herbert Xu wrote: > On Sun, Jun 23, 2019 at 11:30:41AM +0200, Ard Biesheuvel wrote: >> >> So with that in mind, I think we should decouple the multi-sector >> discussion and leave it for a followup series, preferably proposed by >> someone who also has access to some hardware to prototype it on. > > Yes that makes sense. Yes. And TBH, the most important optimization for dm-crypt in this case is processing 8 512-bytes sectors in 4k encryption block (because page cache will generate page-sized bios) and with XTS mode and linear IV (plain64), not ESSIV. Dm-crypt can use 4k sectors directly, there are only two blockers - you need LUKS2 to support it, and many devices just do not advertise physical 4k sectors (many SSDs). So switching to 4k could cause some problems with partial 4k writes (after a crash or power-fail). The plan for the dm-crypt side is more to focus on using 4k native sectors than this micro-optimization in HW. Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
