Re: [dm-crypt] dm-crypt on raid 5 - having all disks on single controller makes dm-crypt slower

["\"C. Dominik Bódi\"" <dominik.bodi@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

Am 26.02.2014 00:58, schrieb shmick@riseup.net:
> *only* 150 ?
> there's lots of numbers here but maybe we should work backwards and KIS
> ask yourself what do you want to achieve ?
> when you know the results you want and/or need (2 different things) you
> can work backwards & figure out out how to get there
> do you *need* to have a certain read/write speed for your application or
> desired conclusion in mind ?
Well, yes, I'd like to have as much throughput as possible. The cpu is a
quad core with HT, so could dm-crypt not utilize 4 threads when there
are 4 disks in the raid5 array.

An the thing is:

4 disks on controller A => dm-crypt 150MB/s
2 disk on controller A, 2 disks on controller B => dm-crypt 300MB/s

I don't understand that behaviour. Why does it make a difference for
dm-crypt if the disks sit on different controllers or not? Why should I
waste speed when dm-crypt could easily utilize 4 worker threads and max
out the raid5 performance? Why doesn't it do so automatically. Is there
any means to make dm-crypt use 4 threads even if all 4 drives sit on a
single controller?

I know the simple answer would be to reverse the stack, encrypt each
raid drive singularly and then put the raid5 array on top of the
encrypted drives. That makes it really difficult to unlock the drives
remotely (via dropbear in the initramfs), though.

> do you have a recent version of cryptsetup with the benchmark option ?
> that can give you an idea of in memory performance and depends on your
> CPU & chosen ciphers/hashes
I'm using aes-xts-plain64 with 256 key size. The benchmark shows me a
throughput of 175 MB/s. I reckon the benchmark only runs a single
thread, so that seems to be ok.

> i didn't quite get if your RAID is a hardware or software array ?
Hmmm, sorry for that oversight. Yes, it is a software raid5 array set up
with mdadm.

> i'll leave that to the experts ;-)
Yes, indeed, I was looking for an answer from someone that knows the
dm-crypt kernel code quite well.

Regards,
Dominik


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]