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
signature.asc
Description: Digital signature
