On 2019/10/26 下午5:23, Christian Pernegger wrote: > Am Sa., 26. Okt. 2019 um 02:01 Uhr schrieb Qu Wenruo <quwenruo.btrfs@xxxxxxx>: >> It's already working, the problem is, there is a dirty log while >> nologreplay mount option doesn't really work. > > For the record, I didn't try to mount using nologreplay, only > notreelog. (Apologies if notreelog and/or skipbg imply nologreplay.) Then that's the problem. With skipbg, all block groups are marked readonly, any write should go a ENOSPC error. Thus I put a log tree check in skipbg mount option, and if it detects log tree, it refuse to mount and output kernel message to require nologreplay. > >> You can btrfs-zero-log to clear the log, then try again using skipbg >> mount option. > > I don't think I can, actually. At least, zeroing the log didn't work > back when btrfs check --repair was still in the table. Admittedly, > that was using Ubuntu eoan's 5.3 kernel, not yours, and with their > btrfs-progs (5.2.1); I don't think I'd gotten around to compiling > btrfs-progs 5.3, yet. So if you think trying again with the > rescue_options kernel and/or latest btrfs-progs might allow me to zero > the log, I'll try again. > Alternatively, using backup super 1 or 2 got me past that hurdle with > btrfs check --repair, so if there's an option to mount using one of > these ...? > (Output quoted below for reference.) > >>> $ btrfs check --init-extent-tree patient >>> Opening filesystem to check... >>> Checking filesystem on patient >>> UUID: c2bd83d6-2261-47bb-8d18-5aba949651d7 >>> repair mode will force to clear out log tree, are you sure? [y/N]: y >>> ERROR: Corrupted fs, no valid METADATA block group found >>> ERROR: failed to zero log tree: -117 >>> ERROR: attempt to start transaction over already running one >>> # rollback >>> >>> $ btrfs rescue zero-log patient >>> checksum verify failed on 284041084928 found E4E3BDB6 wanted 00000000 >>> checksum verify failed on 284041084928 found E4E3BDB6 wanted 00000000 >>> bad tree block 284041084928, bytenr mismatch, want=284041084928, have=0 >>> ERROR: could not open ctree >>> # rollback >>> >>> # hm, super 0 has log_root 284056535040, super 1 and 2 have log_root 0 ... >>> [...] > >> And thanks for the report, I'll look into why nologreplay doesn't work. > > On the contrary, thank you! It's the least I can do. If there's > anything else I can to help make it less likely (something like) this > bites me or anyone else again, just say the word. Also, I'm curious as > to the state of the data and btrfs restore doesn't care about > checksums, so I'd love to be able to ro-mount the image sometime. Then you can try btrfs-mod-sb, which modifies superblock without mounting the fs. # ./btrfs-sb-mod /dev/nvme/btrfs log_root =0 Of course, you'll need to compile btrfs-progs. You don't need to compile the full btrfs-progs, which has quite some dependencies, you only need to: # cd btrfs-progs/ # ./autogen.sh # make btrfs-sb-mod Then try above command. You should got something like: $ ./btrfs-sb-mod /dev/nvme/btrfs log_root =0 super block checksum is ok GET: log_root xxxxx (0xXXXXXX) SET: log_root 0 (0x0) Update csum Then try mount with rescue=skipbg,ro again. Thanks, Qu > > Cheers, > C. >
Attachment:
signature.asc
Description: OpenPGP digital signature
