From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, "Qu Wenruo" <wqu@suse.com>,
linux-btrfs@vger.kernel.org,
"Luca Béla Palkovics" <luca.bela.palkovics@gmail.com>
Subject: Re: [PATCH 1/2] btrfs-progs: check: add check and repair ability for super num devs mismatch
Date: Thu, 24 Mar 2022 07:38:06 +0800 [thread overview]
Message-ID: <5aa9f195-9152-72fb-e053-a67b734dcb34@gmx.com> (raw)
In-Reply-To: <f52f4d7e-1d9e-9680-3aa5-ef954f0135b2@gmx.com>
On 2022/3/24 07:15, Qu Wenruo wrote:
>
>
> 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.
Indeed that's the case.
Fix upon current devel branch is:
https://lore.kernel.org/linux-btrfs/f576d7a548b91d42d02b17d2dc52ee04d943a57d.1648077794.git.wqu@suse.com/T/#u
Please fold the fix into the patch.
Thanks,
Qu
>
> Will fix it soon.
>
> Thanks,
> Qu
next prev parent reply other threads:[~2022-03-23 23:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-28 0:50 [PATCH 0/2] btrfs-progs: add check and repair ability for super num devices mismatch Qu Wenruo
2022-02-28 0:50 ` [PATCH 1/2] btrfs-progs: check: add check and repair ability for super num devs mismatch Qu Wenruo
2022-03-23 17:43 ` David Sterba
2022-03-23 23:15 ` Qu Wenruo
2022-03-23 23:38 ` Qu Wenruo [this message]
2022-02-28 0:50 ` [PATCH 2/2] btrfs-progs: tests/fsck: add test case " Qu Wenruo
2022-03-23 17:12 ` [PATCH 0/2] btrfs-progs: add check and repair ability for super num devices mismatch David Sterba
2022-03-23 17:17 ` David Sterba
2022-03-23 23:30 ` Qu Wenruo
2022-03-24 15:12 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5aa9f195-9152-72fb-e053-a67b734dcb34@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=luca.bela.palkovics@gmail.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox