Re: mounting failed any file on my filesystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux