On Tue, Aug 30, 2016 at 4:08 AM, Lindsay Mathieson
On 30/08/2016 7:57 PM, Carlos E. R. wrote:
But nothing new in this area. Nothing like "debacle over RAID 5/6" that Lindsay mentioned.
Or is he referring to a new implementation of raid? :-? I thought I heard of a raid implementation peculiar to btrfs.
"Btrfs RAID 5/6 Code Found To Be Very Unsafe & Will Likely Require A Rewrite"
http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-56-Is-Bad
The btrfs scrub recalculates the wrong parity for raid 5/6 volumes, the bug has existed for years - probably the cause for a recovery failure bug the btrfs team have been trying to track down.
This is overstated. Parity is not always recalculated incorrectly. It first requires a bad data strip, and second it requires a scrub, during which data csum mismatch happens, then the data is correctly reconstructed and repaired from good parity, and then *sometimes* bad parity is recomputed and written to disk. It's not clear that this happens passively (during normal reads), or with balance code, as it's only been reproduced with existing corruption of a data strip and during scrubs. And it doesn't cleanly reproduce, the original reproducer and I only found it happening about 1 in 3 attempts. So it's actually rather obscure, which in no way discounts how bad a bug it is. Next, Photonix doesn't bother to point out that Duncan isn't a developer, or kernel developer, or Btrfs developer (and neither am I). Duncan states this fact in fully half, or more, of his posts. So while I agree with his opinion that Btrfs raid56 is only suitable for testing, I can't agree with the broad statement that Btrfs raid56 is so problematic that it has to be totally scraped and rewritten. That isn't knowable to those unfamiliar with Btrfs code. It might very well be there are a handful of obscure yet treacherous bugs that can eventually be found and fixed. A much bigger problem, affecting more users, for all consumer drive configurations whether single drive or in some kind of raid (LVM, mdadm, Btrfs, and maybe even ZFS on Linux): http://www.spinics.net/lists/raid/msg52800.html http://www.spinics.net/lists/raid/msg53389.html It comes up probably once a week or two, and people lose data because of this (now) very common misconfiguration. Another big problem for Btrfs multiple device support is the lack of faulty device handling. Btrfs will continue to read and write to bad devices, indefinitely, spewing errors the entire time which itself sometimes causes problems (not least of which is the log spamming that ensues). There are patches available for testing upstream that aren't yet merged because they haven't had enough testing. So if people want this to get better, more will have to step up and do some testing with sane hardware setups, in simple configurations, without any other out of tree patches or kernel modules, and be completely OK with actually having to used their backups. In something like 7 years now, I've had no data loss with Btrfs. I have had a couple arrays implode such that they became read only, so they had to be recreated; and in both cases there was a user induced event that caused the degraded state to happen, during which a bug was triggered that results in the read only state. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org