My intuition is that performance questions are too volatile to put into the FAQ. And to dependent on the actual details of the target system, i.e. most people will actually have to benchmark on their own set-up to find out what _they_ get. <rant> One thing is for sure, more layers do not make things better. Hence I do not have any LVM set-up. A second problem with LVM is that it complicates things vastly in case something goes wrong and you need to do data-revocery. KISS applies. (Personally, I think LVM is a complicated, intransparent monster that adds complexity where it is rarely needed...) As to MD, I still use superblock format 0.90, because assembling an array ist clearly the controllers job (i.e. the kernels), hence I use it with kernel-level autodetection. Several people have told me that was stupid, but my impression of the newer superblock formats is that they are made by a chaotic horde that had no clue what they wanted to achive, increase complexity with out need and are generally messed up and hence violate KISS. With 0.90 at least I can find the data on disk manually if something breaks without understanding some convoluted line of reasoning, so I will keep using it until it breaks (which may well be never). And 0.90 superblocks go into a place where they cannot kill LUKS headerts, a definitive advantage. </rant> Arno On Sun, Jul 07, 2013 at 10:30:44PM +0200, Christoph Anton Mitterer wrote: > 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 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
