On Thu, Jun 23, 2016 at 10:56 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Chris Murphy posted on Thu, 23 Jun 2016 18:54:28 -0600 as excerpted: > >> From the pasted kernel messages: >> >>> Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version >>> 4.8.5 (Gentoo 4.8.5 p1.3, pie-0.6.2) ) #2 SMP Tue May 24 20:34:19 UTC >>> 2016 >> >> >> 3.18.34 is ancient. Find something newer and try to remount normally. >> And then also with recovery if necessary (don't use ro, see if it'll >> mount rw and fix itself). And if not, then try btrfs check with a newer >> version of btrfs-progs, I can't tell from the pasted output what version >> you're using but since the kernel is so old, decent chance the btrfsck >> is old also. > > ... So I guess that means we're back to supporting only the latest two > LTS kernel series, those being 4.1 and 4.4 at this time. I had hoped > that btrfs was stabilizing enough, and 3.18 was trouble-free enough btrfs- > wise, that we could expand that to three LTS series now, as the > indications were we might when 4.4 was still new. But it seems that > while we did support it a bit longer, say 2.5 LTS series, that couldn't > continue until the /next/ LTS came out. > > Oh, well, it /was/ a bit of a stretch...
Yeah looks like 3.18.35 even has some backports, and it's not that old but I have no idea if the problem in this case if fixed by something newer. I'd say 50/50 shot at a new kernel doing better, but for the sure the btrfs-progs has a better chance because btrfsck has had lots of improvements since 3.18. It's just too easy to dd a Fedora 24 live image to a USB stick, which has kernel 4.5.5 and btrfs-progs 4.5.2 and give it a shot. And if that doesn't work, then btrfs-image time so hopefully devs can see if it's possible to improve btrfsck. But at that point it also means blowing away this fs :-\ but at least it's ro mountable so anything important can be copied off normally. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
