On Mon, Jul 08, 2013 at 10:41:27PM +0200, Christoph Anton Mitterer wrote: > On Mon, 2013-07-08 at 19:48 +0200, Arno Wagner wrote: > > My intuition is that performance questions are too volatile > > to put into the FAQ. > Well AFAICS that would apply only to Q3 then... and well... I didn't > mean to give any real world values but rather telling people about some > caveats like that placing MD above dmcrypt is not so good for RAID 4,5,6 That I have in FAQ item 2.6. It is also not a good idea for RAID 1, as you have to open multiple containers before yoru RAID can be assembled. Conceptually, you should encrypt the filesystem, not the raw block devices. > (Neil wrote over at linux-raid, that the issues described by Milan are > no longer true for levels 1 and 10). > I mean the situation is now that all these legacy rumors and information > is floating around in dozens of howtos... so either people have no idea > what they're doing (and thus suffer performance)... or we should tell > em. See FAQ item 2.6. > > > 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. > Sure but that doesn't apply to general principles or stuff. > > > > > 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...) > Well the only alternative (for the scenarios in which one wants to use > LVM) would be to create partitions on top of dmcrypt... is that possible > at all? It is. But KISS-wise it is even more of a problem. > > 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. > Well you can easily screw your RAID with that... and I think it's > generally deprecated... I have not lost a single array in > 10 years with that. I have not idea how you could "easily screw your RAID with that". I think the deprecation is just because some people try to hide the mess they made with the newer superblock placement and with missing autodetection. > I do not even know whether it would e.g. work with GPT... and IIRC it > does (obviously) not work with the RAID modules not compiled into the > kernel... not to talk about other limitations of the v0 superblock. For a reliable RAID setup, the code obviosuly belongs statically into the kernel. But AFAIK, the autodetection then just happens on module load. > > With 0.90 at least I can find > > the data on disk manually if something breaks without > > understanding some convoluted line of reasoning > I guess you mean "mount" with find... which is obviously only possible No, I very explicitely mean not "mount", I mean "find", i.e. partition, offset, length. If I mount a RAID1 component, it will either be ro or manually resynced afterwards. > with RAID1,... even that can be done with the v1 superblocks (out of the > box with 1.0)... and if you just set an offset... also with the others. > > And directly mounting a RAID1 is really a dangerous thing, when one > doesn't know what one's doing or when it happens accidentally (which is > easy with 0.9 and 1.0 superblocks)... your RAID1 can get dirty without Never happened to me. If used with autodetection, they are already in use whan it could happen. Another reason why it is the kernel's job to assemble RAID arrays, not some script's job later. > it ever noticing it (thus likely data corruption). I know, I have been using Linux software RAID for a long time. And I have done the one or other data recovery from RAID1. Arno -- 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
