On 2018/11/6 下午4:17, Attila Vangel wrote: > 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 As expected, since extent tree is corrupted, btrfs check can't do much help. This is definitely something we could enhance, although it will take a long time for btrfs-progs to handle such case, then some super hard kernel mount option for kernel to do pure RO mount. > > (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. Nice idea. Maybe we could enhance btrfs-restore to that direction. Thanks, Qu > > 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 >>
Attachment:
signature.asc
Description: OpenPGP digital signature
