Duncan <1i5t5.duncan <at> cox.net> writes: > FWIW, btrfs raid5 (and raid6, together called raid56 mode) is still > extremely new, only normal runtime implemented as originally introduced, > with complete repair from a device failure only completely implemented in > kernel 3.19, and while in theory complete, that implementation is still > very immature and poorly tested, and *WILL* have bugs, one of which you > may very well have found. > > For in-production use, therefore, btrfs raid56 mode, while now at least > in theory complete, is really too immature at this point to recommend. > I'd recommend either btrfs raid1 or raid10 modes as more stable within > btrfs at this point, tho by the end of this year or early next, I predict > raid56 mode to have stabilized to about that of the rest of btrfs, which > is to say, not entirely stable, but heading that way. > Hi Duncan, Thanks for your reply. I was under the impression that RAID5/6 was considered quite stable in the more recent kernels, hence my use of the 3.19 kernel and the upgraded btrfstools. It's obvious that I was wrong in this assumption and maybe btrfs RAID5 should be labeled as experimental code then. A balance operation is supposed to be safe as it makes a copy of each file, rewrites it, distributing the data over all devices and only then deletes the original file? This should never lead to kernel deadlocks ... Having a corrupted filesystem after a reboot due to this is even more worrisome, I think. And worst of all are the btrfs kworker crashes. Kernel code should never crash IMHO, but maybe I'm slightly naive here ;-) . Anyways, lots of lessons learned, and I'll see if I can repair the filesystem as described in https://btrfs.wiki.kernel.org/index.php/Btrfsck If it doesn't work, I'll simply start over with an alternative filesystem. Regards, Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
