<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thank you all for your advises. <br><br>Meanwhile, I have read Practical Cryptographic Data Integrity Protection with Full Disk Encryption Extended Version (1 jul 2018). Very interesting publication. :-)<br><br></div><div>1) Performances seems pretty correct for linear access write 4k blocks NO JOURNAL. Nevertheless, you don't indicate how you realise this test (cp, dd, fio tool...?). <br><br></div><div>2) I will reconsider doing again my stack. (No datas on it) Have you any advises related to fs, RAID0, luksformat (type luk2) creation? Indeed, I don't clearly understand this point :<br><i>"dm-integrity interleaves data and metadata and consequently data are not aligned on raid stripe boundary."</i><br></div><div>According to what I inderstand this will kill my RAID0 main goal for getting fast performance.<br></div><div><br></div><div>3) I want integrity features and I want to try the no journal option for performance gain. How to use it ?<br></div><div><span class="gmail-im">cryptsetup -v luksFormat --type luks2 /dev/md127 --cipher aes-gcm-random --integrity aead </span><i>--integrity-no-journal</i><span class="gmail-im"></span></div><div><dl class="gmail-Bl-tag"><dt>4) I am not sure to understand the relation between sector size of each layer of the stack as we introduce a layer (dif) with metadata under dm-crypt layer and above storage devices. Does 4096 bytes must be choosen for all layers? <br></dt><dt><b>--sector-size <bytes></b></dt><dd>Set sector size for use with disk encryption. It must be power of two and
in range 512 - 4096 bytes. The default is 512 bytes sectors. This option
is available only in the LUKS2 mode.
Note that if sector size is higher than underlying device hardware sector
and there is not integrity protection that uses data journal, using this
option can increase risk on incomplete sector writes during a power fail.
If used together with <i>--integrity</i> option and dm-integrity journal,
the atomicity of writes is guaranteed in all cases (but it cost write
performance - data has to be written twice).
Increasing sector size from 512 bytes to 4096 bytes can provide better
performance on most of the modern storage devices and also with some hw
encryption accelerators</dd><dt><br></dt><dt>Thank you very much for explainations. Any links, articles, documents answering to my interrogation are welcomed.(I have already read <a href="https://manpages.debian.org/unstable/cryptsetup-bin/cryptsetup.8.en.html">https://manpages.debian.org/unstable/cryptsetup-bin/cryptsetup.8.en.html</a> and your publication)<br></dt></dl><p>I will try to make the stack again with --debug option.</p><p>King regards<br></p></div><div><br></div><div><br></div><div><br></div><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le ven. 19 oct. 2018 à 08:47, Milan Broz <<a href="mailto:gmazyland@gmail.com" target="_blank">gmazyland@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/10/2018 19:51, Mikulas Patocka wrote:<br>
> On Fri, 12 Oct 2018, laurent cop wrote:<br>
> <br>
>> Hello,<br>
>><br>
>> I have trouble while in top of the stack :<br>
>> mkfs.ext4 /dev/mapper/raid0luks2<br>
>> /dev/mapper/raid0luks2 alignement is offset by 147456 bytes<br>
>> This may result in very poor performance (re-) partitioning is suggested.<br>
>> I have the same pb with mkfs.xfs<br>
> <br>
> Just ignore this warning. dm-integrity interleaves data and metadata and <br>
> consequently data are not aligned on raid stripe boundary.<br>
> <br>
>> I am using following scheme:<br>
>><br>
>> LUKS2 => created with cryptsetup -v luksFormat --type luks2 /dev/md127 --cipher aes-gcm-random --integrity aeae<br>
>> RAID 0 => created with mdadm chunk=32<br>
>> 3 Disks NVME => partition with gdisk (fist sector : 2048)<br>
>><br>
>> I got this information with lsblk -t for each 3 disks, i got the same information.<br>
>> nvmeXn1<br>
>> -> NvmeXn1p1 ALIGN = 0<br>
>> -> md127 ALIGN = 0<br>
>> -> raid0luks2_dif ALIGN = 147456<br>
>> -> raid0luks2 ALIGN = 147456<br>
>> 1) How can I solve my alignment issue?<br>
>><br>
>> 2) Is it normal to have low performances while writing with dd. I was <br>
>> using LUKS previously and I got only one dev mapper. Now I got 2. Does <br>
>> it have a big impact on performances?<br>
>><br>
>> Kind regards.<br>
> <br>
> dm-integrity already slows down writes about 3 times. At this situation, <br>
> trying to align accesses to raid stripe size doesn't make much sense.<br>
<br>
Actually, I think that the alignment reported there does not make any<br>
sense for dm-integrity (here is not a simple offset, data and metadata are interleaved,<br>
there is a journal... Dm-integrity here behaves more like a filesystem - what a single<br>
offset means?<br>
<br>
Anyway, Mikulas disagrees with me to simple remove it :-)<br>
<br>
> If you want to improve performance, you may try to put two dm-ingerity <br>
> images directly on the SSDs and create raid-0 on the top of them. It may <br>
> perform better, but you'll have to benchmark it with the workload you are <br>
> optimizing for.<br>
<br>
You can do this with LUKS2 authenticated encryption as well, but I am not sure<br>
it is good idea - it will eat CPU time for encryption for each raid 0 member.<br>
<br>
Milan<br>
</blockquote></div>