ronnie sahlberg posted on Fri, 14 Apr 2017 09:56:30 -0700 as excerpted: > On Thu, Apr 13, 2017 at 8:47 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote: >> Ank Ular posted on Thu, 13 Apr 2017 14:49:41 -0400 as excerpted: > ... >> OK, I'm one of the ones that's going to "go off" on you, but FWIW, I >> expect pretty much everyone else would pretty much agree. At least you >> do have backups. =:^) >> >> I don't think you appreciate just how bad raid56 is ATM. There are >> just too many REALLY serious bugs like the one you mention with it, and >> it's actively NEGATIVELY recommended here as a result. It's bad enough >> with even current kernels, and the problems are well known enough to >> the devs, >> that there's really not a whole lot to test ATM... > > Can we please hide the ability to even create any new raid56 filesystems > behind a new flag : > > --i-accept-total-data-loss > > to make sure that folks are prepared for how risky it currently is. That > should be an easy patch to the userland utilities. The biggest problem with such a flag in general is that people often use a kernel and userland that are /vastly/ out of sync, version-wise. Were such a flag to be introduced, people would still be seeing it five years or more after it no longer applied to the kernel they're using (because the kernel's what actually does the work in many cases, including scrub). Even making such a warning conditional on kernel version is problematic, because many distros backport major blocks of code, including perhaps btrfs fixes, and the nominally 3.14 or whatever kernel may actually be running btrfs and other fixes from 4.14 or later, by the time they actually drop support for whatever LTS distro version and quit backporting fixes. Besides which, if the patch was submitted now, the earliest it could really hit btrfs-progs would be 4.12, and by the time people actually get that in their distro they may well be on 4.13 or 4.15 or whatever, and the patches fixing raid56 mode to actually work may already be in place. The only place such a warning really works is on the wiki at https://btrfs.wiki.kernel.org , because that's really the only place that can be updated to current status in a realistic timeframe. And there's already a feature maturity matrix there, with raid56 mode marked appropriately, last I checked. Meanwhile, it can be argued that admins (and anyone making the choice of filesystem and device layout they're going to run is an admin of those systems, even if they're just running them at home for their own use) who don't care enough about the safety of their data to actually research the stability of the filesystem and filesystem features they plan to use... really don't value that data very highly in the first place. And the status is out there both on this list and on the wiki, so even a trivial google should find it without issue. Indeed: https://www.google.com/search?q=btrfs+raid56+stability -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
