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:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
