Re: [dm-crypt] dm-crypt + mdadm

[Milan Broz <gmazyland@gmail.com>]

On 22.11.2013 23:53, Arno Wagner wrote:
> My bottom line is that
> a) I do not trust the CentOS "stable" kernel one bit.
> b) 2.6.32 is so old, doing anything on it to improve
>     performance is probably a waste of time. 2.6.32 is 4 years
>     old by now and the 2.6.x line is 10 years old...


Sorry, but this is way too far generalization and typical mistake
with "enterprise" kernels :)

2.6.32 is baseline for REHL6/CentOS 6 kernels. But many patches
are backported there and it get a lot of more testing.
(And CentOS should be just rebuild of RHEL kernel.)

Yes, they can mess things up sometimes, that's why there are stable
kernels (no new features) and paid support for RHEL.

In many areas kernel number means nothing, it contains
features from 3.12 etc (specially for device-mapper it is
almostalways true).

(And my experience is that RHEL/CentOS kernel are pretty stable
in comparison with manual upstream builds. I would not
suggest any customer to build own kernel for these enterprise distributions
- note you need to update and maintain userspace bit as well,
handle security updates and you have to know some internal differences.)

But in the RHEL6 dmcrypt case: yes, there is single threaded implementation
(every dmcrypt device has own single thread). This is kind of exception,
because usually RHEL device-mapper stack follows upstream.

This is no longer true for upstream where it uses per-cpu threads
(limitation is that it always processes work on cpu which submitted it,
so there are still some issues).

Backporting this to RHEL6 is near to impossible (not only technical
reasons, think certification etc) but I cannot speak for Red Hat anymore.
(Just you can be sure you are not the first requesting it and I spent
quite a lot time playing with it.)

So complaining to RHEL/CentOS kernel here makes no sense, please
fill bugzilla or use their support channel.

For upstream, please test current kernel. You should get better
performance (depends on scenario).

(Mikulas posted several times another approach to dmcrypt parallelization
bus I am still not convinced it really helps. And currently there are some
changes upstream in MD and block devices subsystem which influences it as well).

Anyway, general suggestion now is to use fast CPU with AES-NI switched on.
(This can saturate even very fast RAID arrays with single thread,
IIRC I saw throughput >500MB for recent server hw & RHEL6 kernel).

Milan