On Samstag, 31. Dezember 2016 05:05:03 CET Duncan wrote: > Jan Koester posted on Fri, 30 Dec 2016 13:17:37 +0100 as excerpted: > > sudo btrfs filesystem df /mnt > > Data, RAID6: total=1.22TiB, used=0.00B > > System, RAID6: total=96.00MiB, used=0.00B > > Metadata, RAID6: total=8.25GiB, used=80.00KiB > > GlobalReserve, single: total=512.00MiB, used=8.00KiB > > Expanding on what I already mentioned in passing (hoping it wasn't the > case), raid56 mode (so including your raid6) remains quite unstable, with > known problems that make it unsuitable for the sort of purposes people > normally run parity-raid for. So it's actively negatively recommended > unless you're running it for the specific purpose of trying to help the > devs work out the problems with it, using only throw-away-value test data > in case those problems eat it, which unfortunately they have a > significantly real chance of doing, with raid56 at this point. > > So you need to get off of it ASAP, and hope any data that wasn't already > throw-away-value, doesn't end up being thrown away anyway, in the process. > > Unfortunately, as I said in the earlier post, I'm just a user, tho a list > regular, myself, not a dev. And I've been staying well away from raid56 > /because/ of these problems (as well as because it didn't fit my use-case > in the first place), so other than noting the severity of the issues, > I've not really been paying attention to the various threads with people > trying to fix the problems and save at least some of their raid56 stored > data. > > So if you want to try to save the data, you'll need help from a dev or > higher level expert, or failing that, at least to examine the last couple > 2-3 months worth of list threads and find the raid56 ones with methods to > try to save what can be saved, and possibly to patch at least some of the > problems in ordered to not make the problem worse while you're doing so. > > But it's going to require some reasonable technical know-how to try to do > that, as well as the time and hassle, so honestly, unless that data's > /really/ worth it, it may be better to simply cut and run, doing a fresh > mkfs and being done with btrfs raid56 for now, without spending more time > on it, only to find you can't save much anyway. Tho if it's worth it to > you, you may be able to save much of it, but you could spend a month's > man-hours doing it too and possibly still come up empty. Plus be > careful, because stuff like scrub that would normally help, can make the > problem much much worse in the case of raid56 ATM. Yes, the problems > with it ATM *are* that bad. Unfortunately. There's actually talk of > scrapping the code (almost?) entirely and starting over again, as there's > a real question as to whether it can even be properly fixed, tho I'm not > sure it will come to that. I have backup of this data i wan't to help the Dev's too fix this bug because i have enough hard drives.I can also give remote access to show what happend with the filesystem or other thins that could he to fix this bug. I see at the moment much things happened on the raid56 code. -- 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
