On Thu, Jun 23, 2016 at 10:56 PM, Duncan [off-list ref] wrote:

Chris Murphy posted on Thu, 23 Jun 2016 18:54:28 -0600 as excerpted:

quoted

From the pasted kernel messages:

quoted

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