[dm-crypt] some questions and FAQ suggestions

[Christoph Anton Mitterer <calestyo@scientia.net>]

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

Hi Arno, Milan, et al.


I recently asked some questions[0],[1] over at the linux-raid list and
some of them were about how things are when one stacks the typical DM
layers (MD, dmcrypt, LVM) in different order, I guess most reasonable
use cases would be either of these:
physical medium -> MD -> LVM -> dmcrypt        -> filesytem
physical medium -> MD        -> dmcrypt -> LVM -> filesytem
or maybe even:
physical medium -> MD -> LVM -> dmcrypt -> LVM -> filesytem

Optionally having partitions in between phyiscal medium and MD - but I
guess this shouldn't really change anything (correct me if I'm wrong),
neither with respect to performance, nor with respect to functionality
(i.e. how commands or techniques like TRIM, or barriers are passed
through).


Some discussion (especially about performance) with respect to the (old)
fact that dmcrypt was single-threaded arose in [1].
I asked Milan off list to share some light which he did[2,3] (thanks
again).


I think most of what he says should be added to the FAQ, for people that
also search on this (perhaps referring those threads as well), like:

Q1: Does dmcrypt work with DM/block device barriers and filesystem
barriers?
(AFAIU, these are different barrier technologies?)


Q2: Are there any technological/functional/security issues when stacking
dmcrypt with LVM and/or MD (at any order of these)?
I.e. is TRIM supported in any stacking order? Are there any other
subtle/major issues depending on the ordering of these? Or issues that
could lead to data corruption or out-of-sync RAIDs, whatsoever.


Q3: Are there any performance issues when stacking dmcrypt with LVM
and/or MD (at any order of these), assuming that the different layers
have the correct block/chunk/phsical extent alignment?
(not sure whether, if unaligned to physical extents from LVM, would
actually cause troubles or not?)

There probably noting the thing about single/multi-threaded and that MD
makes IO from one CPU, so that MD should always be below dmcrypt (for
performance reasons at least).



Milan noted that one should also tell how things were before these
patches... I'd say it should be at least noted that this changed at one
point... whether the situation before needs to described in-depth, I
have no strong opinion.




There are some questions of my MD questions I haven't yet gotten any
real answers (especially how MD actually reads/writes data/parity
blocks, i.e. how much is at least always FULLY read/written)... and I'd
have basically the same question for dm-crypt (and I think it's not yet
in the FAQ).
So IMHO answering the following would be interesting:

Q4: Depending on the chosen cipher/size/modes, which there a minimum
block size that dmcrypt always fully reads/writes?

I always though that this is _always_ (even if you have 4KiB blocks
below or so) the 512B... which are fully read/written (respectively
decrypted/encrypted), right?

Milan, I saw [4], which AFAIU means that we may sooner or later get
block sizes > 512B.
So the question might arise how large block sizes would affect
interaction (especially performance) with the other layers like MD (i.e.
would it be a problem if the dmcrypt block size is larger than the
smalles block size that MD always fully/reads writes... when either is
on top of the other).



Cheers,
Chris.


[0] http://thread.gmane.org/gmane.linux.raid/43405
[1] http://thread.gmane.org/gmane.linux.raid/43406
[2] http://thread.gmane.org/gmane.linux.raid/43406/focus=43450
[3] http://thread.gmane.org/gmane.linux.raid/43406/focus=43452
[4] http://code.google.com/p/cryptsetup/issues/detail?id=156

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5113 bytes --]