On 2019/10/26 下午5:23, Christian Pernegger wrote:
> Am Sa., 26. Okt. 2019 um 02:01 Uhr schrieb Qu Wenruo <quwenruo.btrfs@gmx.com>:
>> 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.
>