Re: LUKS2 - RAID0 - NVME : alignment issue

From: Milan Broz <gmazyland@gmail.com>
To: Mikulas Patocka <mpatocka@redhat.com>,
	laurent cop <laurent.cop@gmail.com>
Cc: dm-devel@redhat.com
Subject: Re: LUKS2 - RAID0 - NVME : alignment issue
Date: Fri, 19 Oct 2018 08:47:33 +0200	[thread overview]
Message-ID: <2cd7ddd8-6c3c-e420-fd1f-44912f24ca66@gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1810181342200.19328@file01.intranet.prod.int.rdu2.redhat.com>

On 18/10/2018 19:51, Mikulas Patocka wrote:
> On Fri, 12 Oct 2018, laurent cop wrote:
> 
>> Hello,
>>
>> I have trouble while in top of the stack :
>> mkfs.ext4 /dev/mapper/raid0luks2
>> /dev/mapper/raid0luks2 alignement is offset by 147456 bytes
>> This may result in very poor performance (re-) partitioning is suggested.
>> I have the same pb with mkfs.xfs
> 
> Just ignore this warning. dm-integrity interleaves data and metadata and 
> consequently data are not aligned on raid stripe boundary.
> 
>> I am using following scheme:
>>
>> LUKS2           => created with cryptsetup -v luksFormat --type luks2 /dev/md127 --cipher aes-gcm-random --integrity aeae
>> RAID 0           => created with mdadm chunk=32
>> 3 Disks NVME => partition with gdisk (fist sector : 2048)
>>
>> I got this information with lsblk -t for each 3 disks, i got the same information.
>> nvmeXn1
>>        -> NvmeXn1p1                                 ALIGN = 0
>>                   -> md127                               ALIGN = 0
>>                            -> raid0luks2_dif           ALIGN = 147456
>>                                        -> raid0luks2     ALIGN = 147456
>> 1) How can I solve my alignment issue?
>>
>> 2) Is it normal to have low performances while writing with dd. I was 
>> using LUKS previously and I got only one dev mapper. Now I got 2. Does 
>> it have a big impact on performances?
>>
>> Kind regards.
> 
> dm-integrity already slows down writes about 3 times. At this situation, 
> trying to align accesses to raid stripe size doesn't make much sense.

Actually, I think that the alignment reported there does not make any
sense for dm-integrity (here is not a simple offset, data and metadata are interleaved,
there is a journal... Dm-integrity here behaves more like a filesystem - what a single
offset means?

Anyway, Mikulas disagrees with me to simple remove it :-)

> If you want to improve performance, you may try to put two dm-ingerity 
> images directly on the SSDs and create raid-0 on the top of them. It may 
> perform better, but you'll have to benchmark it with the workload you are 
> optimizing for.

You can do this with LUKS2 authenticated encryption as well, but I am not sure
it is good idea - it will eat CPU time for encryption for each raid 0 member.

Milan

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel