Re: [PATCH 1/2] btrfs-progs: check: add check and repair ability for super num devs mismatch

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/3/24 01:43, David Sterba wrote:
> On Mon, Feb 28, 2022 at 08:50:07AM +0800, Qu Wenruo wrote:
>> [BUG]
>> There is a bug report of kernel rejecting fs which has a mismatch in
>> super num devices and num devices found in chunk tree.
>>
>> But btrfs-check reports no problem about the fs.
>>
>> [CAUSE]
>> We just didn't verify super num devices against the result found in
>> chunk tree.
>>
>> [FIX]
>> Add such check and repair ability for btrfs-check.
>>
>> The ability is mode independent.
>>
>> Reported-by: Luca Béla Palkovics <luca.bela.palkovics@gmail.com>
>> Link: https://lore.kernel.org/linux-btrfs/CA+8xDSpvdm_U0QLBAnrH=zqDq_cWCOH5TiV46CKmp3igr44okQ@mail.gmail.com/
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>
> With this patch applied there's a new test failure:
>
> === START TEST .../tests/fsck-tests/014-no-extent-info
> testing image no_extent.raw.restored
> ====== RUN MUSTFAIL .../btrfs check ./no_extent.raw.restored
> Opening filesystem to check...
> Checking filesystem on ./no_extent.raw.restored
> UUID: aeee7297-37a4-4547-a8a9-7b870d58d31f
> cache and super generation don't match, space cache will be invalidated
> found 180224 bytes used, no error found
> total csum bytes: 0
> total tree bytes: 180224
> total fs tree bytes: 81920
> total extent tree bytes: 16384
> btree space waste bytes: 138540
> file data blocks allocated: 0
>   referenced 0
> succeeded (unexpected!): .../btrfs check ./no_extent.raw.restored
> unexpected success: btrfs check should have detected corruption


Weird, the problem is, for the restored image, if I run ./btrfs check
manually it can detects the problem, but still go "no error found" path.

So it must be my patch overriding the return value.

Will fix it soon.

Thanks,
Qu