Please do not send HTML-Email to this list...
Arno
On Thu, Nov 27, 2014 at 16:24:40 CET, Mark Connor wrote:
> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
> <style type="text/css"><!--p { margin-bottom: 0.1in; line-height: 120%; }
> --></style>
> <p style="margin-bottom: 0in; line-height: 100%">Hello</p>
>
> <p style="margin-bottom: 0in; line-height: 100%"> </p>
>
> <p style="margin-bottom: 0in; line-height: 100%">Exactly this is why I started the topic:</p>
>
> <p style="margin-bottom: 0in; line-height: 100%"> </p>
>
> <p style="margin-bottom: 0in; line-height: 100%">"Say the mirrors are incosistent due to an unnoted read error, the RAID</p>
>
> <p style="margin-bottom: 0in; line-height: 100%">layer can not decide which of the two legs has faulty data. It can<br/>
> whatsoever reread both legs in hope the faulty read is corrected on reread<br/>
> and rewrite afterwards. I fear such actions are only taken during a forced<br/>
> rebuild though."</p>
>
> <p style="margin-bottom: 0in; line-height: 100%"> </p>
>
> <p style="margin-bottom: 0in; line-height: 100%">Back in 2005 when I was working a lot with servers built of commodity hardware (crappy asus motherboards with their *fake* raid controllers on board) I saw lots of interesting things. That was about the time when I lost my faith in RAID technologies forever. I rather make backups to tapes, cds, other drives periodically and stacking them up somewhere.</p>
>
> <p style="margin-bottom: 0in; line-height: 100%"> </p>
>
> <p style="margin-bottom: 0in; line-height: 100%">Some of the worst failures I saw were corrupted RAID5 arrays with ext3, reiserfs, xfs. These corruptions mostly happened because of regular power outages and whenever I had to deal with them I know the chances to get any data back is less than 20% and then we don't even talk about any encryption just regular filesystems in raid.</p>
>
> <p style="margin-bottom: 0in; line-height: 100%"> </p>
>
> <p style="margin-bottom: 0in; line-height: 100%">How does LUKS handles if part of the encrypted disk (not the header) or container gets corrupted?</p>
>
> <p style="margin-bottom: 0in; line-height: 100%">With some encryption technologies even if 1 bit gets damaged in a container the data lost forever or becomes partially corrupted.</p>
>
> <p style="margin-bottom: 0in; line-height: 100%">So this was back then in the time of slow ATA drives, linux kernel 2.4, raid-utils. Recovery on a 100GB drive took over a day.</p>
>
> <p style="margin-bottom: 0in; line-height: 100%">Today still bunch of low end servers have those fake software raid controllers where you cant even swap a drive without shutting the machine down. Even tho if something goes wrong with an mdadm based raid array you still have more tools, community support and chance to recover data then from a 3ware or hp array.</p>
>
> <div>
> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
> <div style="margin:0 0 10px 0;"><b>Sent:</b> Tuesday, November 25, 2014 at 4:27 PM<br/>
> <b>From:</b> "Sven Eschenberg" <sven@xxxxxxxxxxxxxxxxxxxxx><br/>
> <b>To:</b> dm-crypt@xxxxxxxx<br/>
> <b>Subject:</b> Re: LUKS safety on RAID 1 mirror</div>
>
> <div name="quoted-content">I think Mark was aiming at some other concerns with his question.<br/>
> <br/>
> As you stated, backups are mandatory and RAID's purpose is extended<br/>
> availability (and speed).<br/>
> <br/>
> Regarding the concerns of the OP:<br/>
> When a device fails and gets marked as failed there's no difference to<br/>
> single drive operation. With TLER drives the drive will probably not get<br/>
> marked faulty and the broken sector can be rewritten with the data of the<br/>
> other leg, if that's implemented apropriately.<br/>
> What is problematic in a RAID is failure and unreported errors during<br/>
> read(). Say a sector including the LUKS header is instable, gets read and<br/>
> the retrieved data is faulty then broken data might get written to the<br/>
> mirror during manipulation operations including a following write. (Can be<br/>
> compensated by backups though)<br/>
> With two disks the probability of such a specific error increases, on the<br/>
> other hand a RAID1 implementation *should* level reads which in turn<br/>
> decreases the prob. to hit such a specific read error.<br/>
> <br/>
> The question that remains is: How probable is an unnoted (or unreported)<br/>
> read error and how does the RAID implementation handle specific error<br/>
> scenarios? (Unfortunately there's firmware bugs ...)<br/>
> Say the mirrors are incosistent due to an unnoted read error, the RAID<br/>
> layer can not decide which of the two legs has faulty data. It can<br/>
> whatsoever reread both legs in hope the faulty read is corrected on reread<br/>
> and rewrite afterwards. I fear such actions are only taken during a forced<br/>
> rebuild though.<br/>
> <br/>
> Reagrds<br/>
> <br/>
> -Sven<br/>
> <br/>
> On Tue, November 25, 2014 15:24, Arno Wagner wrote:<br/>
> > On Tue, Nov 25, 2014 at 11:28:47 CET, Fabrice Bongartz wrote:<br/>
> >> Hi Mark,<br/>
> >><br/>
> >> I currently employ the following setup:<br/>
> >> I have multiple md software raid 1 arrays and luks on top of that. For<br/>
> >> example, /dev/sda1 and /dev/sdb1 are two identifcal disks which are in a<br/>
> >> raid1 using md raid as /dev/md0. The luks encrypted device is /dev/md0.<br/>
> >> So far, I have had two discs fail in two different arrays and I have had<br/>
> >> no problem restoring them. The array continued in degrated mode and I<br/>
> >> could safely replace the two drives and add the new disks to the arrays<br/>
> >> using the mdadm command.<br/>
> >><br/>
> >> I am also curious as to what the devs have to say about this.<br/>
> ><br/>
> > RAID and LUKS are in separate layers and do not influence<br/>
> > each other. See FAQ Items 2.2 ad 2.8. 2.8 also has a picture.<br/>
> ><br/>
> > If you place LUKS atop RAID, you get pretty much<br/>
> > the same change as with a normal filesystem atop RAID. Of<br/>
> > course, the LUKS header is critical, which is why you should<br/>
> > always have a header backup, just the same as without RAID.<br/>
> ><br/>
> > If you place LUKS below RAID (not that good an idea), you<br/>
> > will have to unlock the raw devices before the RAID can<br/>
> > be assembled. You should have header backups for as much<br/>
> > devices as are neded to assemble the RAID, but better for<br/>
> > all.<br/>
> ><br/>
> > Really, these are separate issuses, LUKS and RAID do not<br/>
> > magically interact behind your back.<br/>
> ><br/>
> > Gr"usse,<br/>
> > Arno<br/>
> ><br/>
> >> BTW: I always make a complete backup on a third external disk, I don't<br/>
> >> want to take any chances.<br/>
> >><br/>
> >> Cheers,<br/>
> >><br/>
> >> Fabrice Bongartz<br/>
> >><br/>
> >><br/>
> >> Von: "Mark Connor" <markc44@xxxxxxx><br/>
> >> An: "dm-crypt" <dm-crypt@xxxxxxxx><br/>
> >> Gesendet: Dienstag, 25. November 2014 11:03:17<br/>
> >> Betreff: LUKS safety on RAID 1 mirror<br/>
> >><br/>
> >> Hello<br/>
> >><br/>
> >> I currently have a deployment with luks (aes-cbc-256) on different 1TB,<br/>
> >> 500GB, 300GB etc. drives. All the drives use different keys and XFS<br/>
> >> filesystem on the top of luks.<br/>
> >> I'm planning to replace this setup with 2X4TB disks in software raid1<br/>
> >> (with mdraid) but I have my concerns.<br/>
> >><br/>
> >> 1, If a sector goes bad on disk1 that normally shouldn't be replicated<br/>
> >> to disk2 but in case of luks I don't know what happens then.<br/>
> >><br/>
> >> 2, I think it is more practical -when one is dealing with encryption- to<br/>
> >> keep many smaller partitions encrypted with separate keys, in case of<br/>
> >> partial disk failure (other parts of the disk can still be accessed).<br/>
> >> Also all the partitions have their own separate luks headers...<br/>
> >><br/>
> >> Unlike if I don't even create partition just put sda (4TB) sdb(4TB) into<br/>
> >> and md0 array and make luks on that one, if anything goes wrong with the<br/>
> >> header I lose all my data or if any part of the disks breaks.<br/>
> >><br/>
> >> I know that ultimately raid is only protect against drive failures (not<br/>
> >> if files get corrupted or deleted) so have to have a separated<br/>
> >> snapshotted backup next to it. But would implementing raid1 in case of<br/>
> >> luks be an advantage or a disadvantage?<br/>
> >><br/>
> >> Thanks<br/>
> >> _______________________________________________<br/>
> >> dm-crypt mailing list<br/>
> >> dm-crypt@xxxxxxxx<br/>
> >> <a href="http://www.saout.de/mailman/listinfo/dm-crypt"; target="_blank">http://www.saout.de/mailman/listinfo/dm-crypt</a><br/>
> ><br/>
> >> _______________________________________________<br/>
> >> dm-crypt mailing list<br/>
> >> dm-crypt@xxxxxxxx<br/>
> >> <a href="http://www.saout.de/mailman/listinfo/dm-crypt"; target="_blank">http://www.saout.de/mailman/listinfo/dm-crypt</a><br/>
> ><br/>
> ><br/>
> > --<br/>
> > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx<br/>
> > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D<br/>
> > 9718<br/>
> > ----<br/>
> > A good decision is based on knowledge and not on numbers. -- Plato<br/>
> ><br/>
> > If it's in the news, don't worry about it. The very definition of<br/>
> > "news" is "something that hardly ever happens." -- Bruce Schneier<br/>
> > _______________________________________________<br/>
> > dm-crypt mailing list<br/>
> > dm-crypt@xxxxxxxx<br/>
> > <a href="http://www.saout.de/mailman/listinfo/dm-crypt"; target="_blank">http://www.saout.de/mailman/listinfo/dm-crypt</a><br/>
> ><br/>
> <br/>
> <br/>
> _______________________________________________<br/>
> dm-crypt mailing list<br/>
> dm-crypt@xxxxxxxx<br/>
> <a href="http://www.saout.de/mailman/listinfo/dm-crypt"; target="_blank">http://www.saout.de/mailman/listinfo/dm-crypt</a></div>
> </div>
> </div>
> </div></div></body></html>
> _______________________________________________
> 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
----
A good decision is based on knowledge and not on numbers. -- Plato
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
