Re: Problem mounting 4-drive RAID1 fs after replace was interrupted by kernel crash

[Qu Wenruo <wqu@suse.com>]

在 2026/4/1 09:17, Jaron Viëtor 写道:
> On Wed, Apr 1, 2026 at 12:33 AM Qu Wenruo <wqu@suse.com> wrote:
[...]
> 
> That seems to have done the trick!
> 
> BTRFS info (device sdb1): first mount of filesystem
> d18c93f8-d80a-4aa7-adc5-86d457ddde20
> BTRFS info (device sdb1): using crc32c (crc32c-lib) checksum algorithm
> BTRFS info (device sdb1): bdev /dev/sdh1 errs: wr 0, rd 16, flush 0,
> corrupt 1054, gen 0
> BTRFS info (device sdb1): bdev /dev/sdi1 errs: wr 0, rd 0, flush 0,
> corrupt 379, gen 0
> BTRFS info (device sdb1): bdev /dev/sdj1 errs: wr 0, rd 0, flush 0,
> corrupt 1652, gen 0
> BTRFS info (device sdb1): bdev /dev/sdk1 errs: wr 0, rd 0, flush 0,
> corrupt 1522, gen 0
> BTRFS info (device sdb1): start tree-log replay
> BTRFS info (device sdb1): enabling free space tree
> BTRFS info (device sdb1): continuing dev_replace from /dev/sdi1 (devid
> 7) to target /dev/sdb1 @7%
> 
> Thanks for the super fast response, and good luck patching the regression.

Sorry to bother you again, and I wish the replace has finished without 
problem.

If the replace finished, mind to dump the dev tree again?

# btrfs ins dump-tree -t dev <device>

Recently I believe I found another minor bug, that if you have a device 
status item (which records how many errors you hit for that replace 
target device) for the replace target device, it will stay there forever.

Normally that dev stats item should have no errors, but if not the next 
time a new dev-replace is initialized, that new device will inherit that 
old numbers.

It will help a lot if such dump can be provided.

Thanks,
Qu