Robert White schrieb am 08.12.2014 um 18:20: > On 12/07/2014 04:32 PM, Konstantin wrote: >> I know this and I'm using 0.9 on purpose. I need to boot from these >> disks so I can't use 1.2 format as the BIOS wouldn't recognize the >> partitions. Having an additional non-RAID disk for booting introduces a >> single point of failure which contrary to the idea of RAID>0. > > GRUB2 has raid 1.1 and 1.2 metadata support via the mdraid1x module. > LVM is also supported. I don't know if a stack of both is supported. > > There is, BTW, no such thing as a (commodity) computer without a > single point of failure in it somewhere. I've watched government > contracts chase this demon for decades. Be it disk, controller, > network card, bus chip, cpu or stick-of-ram you've got a single point > of failure somewhere. Actually you likely have several such points of > potential failure. > > For instance, are you _sure_ your BIOS is going to check the second > drive if it gets read failure after starting in on your first drive? > Chances are it won't because that four-hundred bytes-or-so boot loader > on that first disk has no way to branch back into the bios. > > You can waste a lot of your life chasing that ghost and you'll still > discover you've missed it and have to whip out your backup boot media. > > It may well be worth having a second copy of /boot around, but make > sure you stay out of bandersnatch territory when designing your > system. "The more you over-think the plumbing, the easier it is to > stop up the pipes." You are right, there is as good as always a single point of failure somewhere, even if it is the power plant providing your electricity ;-). I should have written "introduces an additional single point of failure" to be 100% correct but I thought this was obvious. As I have replaced dozens of damaged hard disks but only a few CPUs, RAMs etc. it is more important for me to reduce the most frequent and easy-to-solve points of failure. For more important systems there are high availability solutions which alleviate many of the problems you mention of but that's not the point here when speaking about the major bug in BTRFS which can make your system crash.
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
