On Apr 23, 2014, at 12:33 PM, Martin Wilck <[email protected]> wrote: > Chris, > >> OpenSUSE 12.3 is using kernel 3.7 which is also old for this sort of >> recovery attempt. Even openSUSE 13.1 is at 3.11.6 which might work in a >> bind, but if it doesn't, inevitably someone will suggest you use something >> even newer. > > Thanks for your reply, I appreciate it a lot. > >> Current stable is 3.14.1, I suggest giving 3.13 or 3.14 a shot at this with >> -o ro,recovery as a first step and see if it at least mounts. > > I will. Note that with 12.3, which was the most recent media I had at > hand at the time, the FS was actually mountable at first (-o > ro,recovery). But there was no /home and later attempts to actually > access data in other subvolumes failed with the messages in my debug > material.
I'd skip 3.13 and go straight to 3.14.1 or 3.15rc2, and use mount option -o ro,recovery straight away and see if you can extract all of /home. You could then try btrfs-progs v3.14's btrfs restore to extract /home. If that doesn't work then I'd give up on this instance of the file system as it sounds damaged by something possibly even the btrfsck --repair. > >> And an old kernel implies old btrfs-progs too, which is where the code for >> btrfsck and btrfs restore is contained. So that needs to be at least v 3.12. >> And hopefully you didn't use --repair with btrfsck yet. > > I did, but I made a block-level copy of the device before. I wouldn't use --repair until a dev recommends it (even with btrfs-progs v3.14 let alone the I'm guessing v0.19 or v0.20 you were using); or once all other reasonable options are exhausted. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
