Hi Qu, Thanks again for the help. In my case: $ sudo btrfs check /dev/nvme0n1p2 Opening filesystem to check... checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000 checksum verify failed on 18811453440 found E4E3BDB6 wanted 00000000 bad tree block 18811453440, bytenr mismatch, want=18811453440, have=0 ERROR: cannot open file system (same with --mode=lowmem). However "btrfs restore" seems to work! (did not have time for the actual run yet) What confused me about "btrds restore" is when I ran a dry run, it just output about a dozen errors about some files, and I thought that's it, no files can be restored. Today I tried it with other options, especially -v shown me that the majority of the files can be restored. I consider myself an intermediate GNU plus Linux user, yet given the stressful situation and being a first time user (btrfs n00b) I missed experimenting with the -v option. So I propose that "btrs restore" should always print a summary line at the end to make it more user friendly (e.g. for the first time users). Something like this: x files restored in y directories[, total size of files is z <human readable unit e.g. GB>]. Use -v command line option for more information. The part in square bracket is optional / nice to have, might be useful e.g. to estimate the required free space in the target filesystem. Cheers, Attila On Tue, Nov 6, 2018 at 2:28 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2018/11/6 上午2:01, Attila Vangel wrote: > > Hi, > > > > TL;DR: I want to save data from my unmountable btrfs partition. > > I saw some commands in another thread "Salvage files from broken btrfs". > > I use the most recent Manjaro live (kernel: 4.19.0-3-MANJARO, > > btrfs-progs 4.17.1-1) to execute these commands. > > > > $ sudo mount -o ro,nologreplay /dev/nvme0n1p2 /mnt > > mount: /mnt: wrong fs type, bad option, bad superblock on > > /dev/nvme0n1p2, missing codepage or helper program, or other error. > > > > Corresponding lines from dmesg: > > > > [ 1517.772302] BTRFS info (device nvme0n1p2): disabling log replay at mount time > > [ 1517.772307] BTRFS info (device nvme0n1p2): disk space caching is enabled > > [ 1517.772310] BTRFS info (device nvme0n1p2): has skinny extents > > [ 1517.793414] BTRFS error (device nvme0n1p2): bad tree block start, > > want 18811453440 have 0 > > [ 1517.793430] BTRFS error (device nvme0n1p2): failed to read block groups: -5 > > [ 1517.808619] BTRFS error (device nvme0n1p2): open_ctree failed > > Extent tree corrupted. > > If it's the only problem, btrfs-restore should be able to salvage data. > > > > > $ sudo btrfs-find-root /dev/nvme0n1p2 > > No, that's not what you need. > > > Superblock thinks the generation is 220524 > > Superblock thinks the level is 1 > > Found tree root at 25018368 gen 220524 level 1 > > Well block 4243456(gen: 220520 level: 1) seems good, but > > generation/level doesn't match, want gen: 220524 level: 1 > > Well block 5259264(gen: 220519 level: 1) seems good, but > > generation/level doesn't match, want gen: 220524 level: 1 > > Well block 4866048(gen: 220518 level: 0) seems good, but > > generation/level doesn't match, want gen: 220524 level: 1 > > > > $ sudo btrfs ins dump-super -Ffa /dev/nvme0n1p2 > > superblock: bytenr=65536, device=/dev/nvme0n1p2 > [snip] > > > > If I understood correctly, somehow it is possible to use this data to > > parametrize btrfs restore to save the files from the partition. > > None of the output is really helpful. > > In your case, your extent tree is corrupted, thus kernel will refuse to > mount (even RO). > > You should run "btrfs check" on the fs to see if btrfs can check fs tree. > If not, then go directly to "btrfs restore". > > Thanks, > Qu > > > Could you please help how to do it in this case? I am not familiar > > with these technical terms in the outputs. > > Thanks in advance! > > > > Cheers, > > Attila > > > > On Thu, Nov 1, 2018 at 8:40 PM Attila Vangel <vangel.attila@xxxxxxxxx> wrote: > >> > >> Hi, > >> > >> Somehow my btrfs partition got broken. I use Arch, so my kernel is > >> quite new (4.18.x). > >> I don't remember exactly the sequence of events. At some point it was > >> accessible in read-only, but unfortunately I did not take backup > >> immediately. dmesg log from that time: > >> > >> [ 62.602388] BTRFS warning (device nvme0n1p2): block group > >> 103923318784 has wrong amount of free space > >> [ 62.602390] BTRFS warning (device nvme0n1p2): failed to load free > >> space cache for block group 103923318784, rebuilding it now > >> [ 108.039188] BTRFS error (device nvme0n1p2): bad tree block start 0 18812026880 > >> [ 108.039227] BTRFS: error (device nvme0n1p2) in > >> __btrfs_free_extent:7010: errno=-5 IO failure > >> [ 108.039241] BTRFS info (device nvme0n1p2): forced readonly > >> [ 108.039250] BTRFS: error (device nvme0n1p2) in > >> btrfs_run_delayed_refs:3076: errno=-5 IO failure > >> > >> At the next reboot it failed to mount. Problem may have been that at > >> some point I booted to another distro with older kernel (4.15.x, > >> 4.14.52) and unfortunately attempted some checks/repairs (?) e.g. from > >> gparted, and at that time I did not know it could be destructive. > >> > >> Anyway, currently it fails to mount (even with ro and/or recovery), > >> btrfs check results in "checksum verify failed" and "bad tree block" > >> errors, btrfs restore resulted in "We have looped trying to restore > >> files in" errors for a dozen of paths then exit. > >> > >> Is there some hope to save data from the filesystem, and if so, how? > >> > >> BTW I checked some diagnostics commands regarding my SSD with the nvme > >> client and from that it seems there are no hardware problems. > >> > >> Your help is highly appreciated. > >> > >> Cheers, > >> Attila >
