Chris Murphy wrote: > > On Nov 2, 2014, at 8:18 AM, Florian Lindner <mailingli...@xgm.de> wrote: > >> Hello, >> >> all after sudden I can't mount my btrfs home partition anymore. System is >> Arch with kernel 3.17.2, but I use snapper which does snapshopts >> regularly and I had 3.17.1 before, which afaik had some problems with >> snapshops. > > It was with creating read-only snapshots. I forget if snapper's snapshots > are ro. If they are then you need to use 3.17 btrfs-progs to fix it. > > >> # btrfsck --init-extent-tree /dev/sdb1 >> root 3377 has a root item with a more recent gen (8589934592) compared to >> the found root node (49443) >> >> # btrfsck --init-csum-tree /dev/sdb1 >> Creating a new CRC tree >> root 3377 has a root item with a more recent gen (8589934592) compared to >> the found root node (49443) > > Did you use btrfs-image before using --repair? > > Once you've done an init-extent-tree and it still won't mount, you're > almost certainly in btrfs restore territory. Get the data out while you > still can. And then you can check the recent patches from Josef for fsck > that aren't yet in btrfs-progs 3.17. I'm not sure if they're in David's > master branch, worth checking. There's a good chance it won't make things > worse, might even fix the file system, but there's a fair chance it'll > totally toast it. So definitely btrfs restore important stuff first.
Ok, problem is that I need to organise another hard disk for that. ;-) I tried restore for a test run, it gave a lot of messages about wrong compression length. I found some discussion about that, but I don't know if its indicates an actual error or not? I did use compression on the drive. Is there some guarantee that the data restore restores are correct or is it just a I try what I can do... Thanks, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
