On Mon, Nov 29, 2010 at 11:42 AM, C Anthony Risinger <anthony@xxxxxxxx> wrote: > On Sun, Nov 28, 2010 at 4:07 AM, C Anthony Risinger <anthony@xxxxxxxx> wrote: >> On Nov 27, 2010, at 10:22 PM, Calvin Walton <calvin.walton@xxxxxxxxx> >> wrote: >>> On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote: >>> >>>> eg. if i have a "regular" directory (not a subvolume) in the top- >>>> level: >>>> >>>> /__boot >>>> >>>> i can mount it with: >>>> >>>> mount -o subvol=__boot /dev/sda /mnt >>> >>> The 'subvol' option actually works using the same mechanism as a bind >>> mount. The fact that it works using a directory is purely a >>> coincidence >>> - I would not expect it to be officially supported, and you shouldn't >>> rely on it. >> >> Hrrrm... Well I thought I'd be clever and use this little trick one >> time to update my kernel... Anyways I oops out like 3 times in a row >> (last func was <something>.clone in each IIRC) and now I'm stuck with >> only my mobile since my server isn't set up yet and my SSD just >> failed on my netbook yesterday :-( >> >> Sooooo, if anyone can help me recover this partition long enough to >> grab a few things... I would be most grateful :-) I think I have >> everything critical, but I'd rather take another look :-) Right now I >> can't mount; mount is failing w/bad superblock. >> >> /me promises to never recklessly sabotage himself after being warned < >> 6 hrs earlier > > any suggestions for me? i dd'ed the corrupt partition to an external > disk because i need the machine back up and running, but if possible > i'd like to get the image running again. i mounted it via loopback > and as expected got the same errors: > > (will post the dmesg output next message -- left at home) > open_ctree_fd failed.... > wanted XXXX found YYYY instead > > the mount command itself fails with "bad superblock or ..." > > i have seen others withe similar crash reports and IIRC correctly were > able to recover it (seems like something just didn't get updated right > before it locked...) > > any ideas? dmesg output was: ------------------------------------------------------ device label root devid 1 transid 61235 /dev/loop0 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 btrfs: open_ctree failed ------------------------------------------------------ i tried btrfsck as suggested in the recent thread: ------------------------------------------------------ # sudo losetup /dev/loop0 /mnt/btrfs.img # sudo btrfsck -s 1 /dev/loop0 using SB copy 1, bytenr 67108864 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root->node)' failed. # sudo btrfsck -s 2 /dev/loop0 using SB copy 2, bytenr 274877906944 No valid Btrfs found on /dev/loop0 ------------------------------------------------------ soooo... does this mean i'm totally boned for ever mounting this image again? or should i keep it around for later? or anything else i can try/do? C Anthony -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
