On Tue, Jul 12, 2011 at 02:10:03PM +0200, Milan Broz wrote: > On 07/12/2011 01:32 PM, Jorge F?bregas wrote: > > That's an interesting question: encrypted raid1 or raid1 of encrypted > > disks? That also could be phrased as "dm-crypt on top of dm-raid" or > > "dm-raid on top of dm-crypt"? > > > > I must admit I would have never thought about a "raid1 of encrypted > > disks" (seems awkward) but apparently it works. I'm new here (and to > > disk encryption at all) but here are my two cents: > > Technically both works. Technically, RAID and encryption are on the same layer of the storage system and you can do arbitrary conbinations. > > # Performance > > I guess from the point of view of performance (CPU-wise) , an "encrypted > > RAID1" would be better as you would be only encrypting once and DM-raid > > will take care of copying those bits as they are to the 2nd disk. I > > suggest you do some tests (copying large amount of data to the encrypted > > disk) and measure it. > > This depends on kernel version and if the system is SMP/multi-cpu. > For <2.6.38 you may get better performance for raid over crypt, > for newer kernel it will be different. > (I am not saying better because there are still performance issues > with crypt over MD Raid. Depends on io pattern and if IO are issued > from different cpus or not. Like dd can be slower but threaded fs test > can have much more better performance.) > > > # Management > > There's no doubt that an encrypted raid1 is much better (much less > > commands: you just need to format once, luksOpen once, luksClose once. > > one backup of the header) > > yes, I would suggest crypt over MD always too. Good point. And you ned to enter your passphrase twice, exposing it more. The main difference security-wise is that an attacker gets the same data-set encrypted with two different keys when RAIDing encrypted devices. That can be a concern. > > # Reliability > > I'm not sure about this part. Let's see what others have to say > > regarding this. > > IMHO both solutions are similar here. Some errors are propagated, > hw failure (RAM, disk) would have similar effect. Reliability with regard to data corryption really belongs into the filesystem-layer and above and into the hysocal device layer. RAID seems to be reliability, but in fact it is redundancy only, and detection of errors (bit errors, unreadable sectors and dead disks) is done below (or for bit-errors possibly in the filesystem-layer with a checksumming FS). The RAID cannot detect errors, it can just react to errors reported by lower layers using the redundancy it provides. One exception: It can do consistency checks, but it can only do somethign about inconsistencioes if it is at least 3-way redundant by voting, i.e. >= 3-way RAID1 or RAID6. And consistency checks are not a normal RAID operation, but rather an externally triggered RAID maintenance operation. > RAID is not backup. You should backup LUKS header and data anyway. Indeed. See FAQ ;-) Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
