On 2019/3/2 上午10:29, Chris Murphy wrote: > On Fri, Mar 1, 2019 at 6:05 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> >> On 2019/3/2 上午8:20, Chris Murphy wrote: >>> Problem happens with btrfsprogs 4.19.1 >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=202717 >>> >>> That bug report includes the trace in user space; but I've also >>> processed the resulting coredump file with gdb and attached that to >>> the bug report. >>> >>> Before using --clear-space-cache v1, btrfs scrub and btrfs check came >>> up clean no errors. Following the crash, I compiled brfsprogs 4.20.2 >>> and ran 'btrfs check' which finds corruption. >>> >>> I've taken no further action, and the btrfs check output gives me no >>> useful plain language information what the next steps are. So I'm just >>> gonna leave it alone since it's a backup volume anyway. >> >> Is the backup volume binary dump of the original fs? > > No. Only btrfs send/receive. > > >> >> I'm interesting why clear space cache v1 doesn't work, to find out that, >> we need tree dump of the original fs. > > btrfs insp dump-t -t 2 ? Or the whole thing? extent tree and root tree. As those are the only trees modified in clear extent tree. Thanks, Qu > >> >> And is the original check done by latest btrfs-progs or v4.19.1? > > The original check is 4.19.1 > The clear cache is 4.19.1 > The subsequent check showing corruption is 4.20.2 but I've found that > it's the same output for 4.19.1 as well. >
Attachment:
signature.asc
Description: OpenPGP digital signature
