On Thu, Jan 26, 2017 at 10:18:40AM +0100, Oliver Freyermuth wrote:
> Hi, 
> 
> I have just encountered on mount of one of my filesystems (after a clean reboot...): 
> [  495.303313] BTRFS critical (device sdb1): corrupt node, bad key order: block=35028992, root=1, slot=243
> [  495.315642] BTRFS critical (device sdb1): corrupt node, bad key order: block=35028992, root=1, slot=243
> [  495.315694] BTRFS error (device sdb1): failed to read block groups: -5
> [  495.327865] BTRFS error (device sdb1): open_ctree failed

   Can you post the output of "btrfs-debug-tree -b 35028992
/dev/sdb1", specifically the 5 or so entries around item 243. It is
quite likely that you have bad RAM, and the output will help confirm
that.

> The system is using a 4.9.0 kernel, and I have btrfs-progs 4.9 installed. 
> 
> Since the last backup is a few weeks old (but the data is not so crucial), I'd like to attempt to recover at least some of the files. 
> 
> btrfs check tells me:
> # btrfs check /dev/sdb1
> Checking filesystem on /dev/sdb1
> UUID: cfd16c65-7f3b-4f5e-9029-971f2433d7ab
> checking extents
> bad block 35028992
> ERROR: errors found in extent allocation tree or chunk allocation
> 
> IIRC, the FS has DUP metadata (but single DATA). It's on a classic spinning disk. 
> I use: "space_cache,noatime,compress=lzo,commit=120" as mount options. 
> 
> What is the best way to go? 
> 
> Should I:
> - reinit extent tree
> - or collect debug info
> - or is there a better way to go?

   Check and fix your hardware first. :)

   If it is bad RAM, then the error is likely to be a simple bitflip,
and there are patches for btrfs check which will fix those in most
cases.

   Hugo.

> Cheers and thanks for any suggestions, 
> 	Oliver
> 
> PS: Please put my mail in CC, I'm not subscribed to the list. Thanks! 

-- 
Hugo Mills             | This: Rock. You throw rock.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                          Graeme Swann on fast bowlers