Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree
To:     =?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?= <davispuh@gmail.com>,
        Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Cc:     clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
References: <20210317012054.238334-1-davispuh@gmail.com>
 <CAOE4rSwj9_DMWLszPE5adiTsQeK+G_Hqya_HkDR=uEC7L4Fj3A@mail.gmail.com>
From:   Qu Wenruo <quwenruo.btrfs@gmx.com>
Message-ID: <20a5d997-740a-ca57-8cbc-b88c1e34c8fc@gmx.com>
Date:   Wed, 17 Mar 2021 18:28:50 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <CAOE4rSwj9_DMWLszPE5adiTsQeK+G_Hqya_HkDR=uEC7L4Fj3A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 2021/3/17 =E4=B8=8A=E5=8D=889:29, D=C4=81vis Mos=C4=81ns wrote:
> tre=C5=A1d., 2021. g. 17. marts, plkst. 03:18 =E2=80=94 lietot=C4=81js D=
=C4=81vis Mos=C4=81ns
> (<davispuh@gmail.com>) rakst=C4=ABja:
>>
>> Currently if there's any corruption at all in extent tree
>> (eg. even single bit) then mounting will fail with:
>> "failed to read block groups: -5" (-EIO)
>> It happens because we immediately abort on first error when
>> searching in extent tree for block groups.
>>
>> Now with this patch if `ignorebadroots` option is specified
>> then we handle such case and continue by removing already
>> created block groups and creating dummy block groups.
>>
>> Signed-off-by: D=C4=81vis Mos=C4=81ns <davispuh@gmail.com>
>> ---
>>   fs/btrfs/block-group.c | 14 ++++++++++++++
>>   fs/btrfs/disk-io.c     |  4 ++--
>>   fs/btrfs/disk-io.h     |  2 ++
>>   3 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
>> index 48ebc106a606..827a977614b3 100644
>> --- a/fs/btrfs/block-group.c
>> +++ b/fs/btrfs/block-group.c
>> @@ -2048,6 +2048,20 @@ int btrfs_read_block_groups(struct btrfs_fs_info=
 *info)
>>          ret =3D check_chunk_block_group_mappings(info);
>>   error:
>>          btrfs_free_path(path);
>> +
>> +       if (ret =3D=3D -EIO && btrfs_test_opt(info, IGNOREBADROOTS)) {
>> +               btrfs_put_block_group_cache(info);
>> +               btrfs_stop_all_workers(info);
>> +               btrfs_free_block_groups(info);
>> +               ret =3D btrfs_init_workqueues(info, NULL);
>> +               if (ret)
>> +                       return ret;
>> +               ret =3D btrfs_init_space_info(info);
>> +               if (ret)
>> +                       return ret;
>> +               return fill_dummy_bgs(info);

When we hit bad things in extent tree, we should ensure we're mounting
the fs RO, or we can't continue.

And we should also refuse to mount back to RW if we hit such case, so
that we don't need anything complex, just ignore the whole extent tree
and create the dummy block groups.

>
> This isn't that nice, but I don't really know how to properly clean up
> everything related to already created block groups so this was easiest
> way. It seems to work fine.
> But looks like need to do something about replay log aswell because if
> it's not disabled then it fails with:
>
> [ 1397.246869] BTRFS info (device sde): start tree-log replay
> [ 1398.218685] BTRFS warning (device sde): sde checksum verify failed
> on 21057127661568 wanted 0xd1506ed9 found 0x22ab750a level 0
> [ 1398.218803] BTRFS warning (device sde): sde checksum verify failed
> on 21057127661568 wanted 0xd1506ed9 found 0x7dd54bb9 level 0
> [ 1398.218813] BTRFS: error (device sde) in __btrfs_free_extent:3054:
> errno=3D-5 IO failure
> [ 1398.218828] BTRFS: error (device sde) in
> btrfs_run_delayed_refs:2124: errno=3D-5 IO failure
> [ 1398.219002] BTRFS: error (device sde) in btrfs_replay_log:2254:
> errno=3D-5 IO failure (Failed to recover log tree)
> [ 1398.229048] BTRFS error (device sde): open_ctree failed

This is because we shouldn't allow to do anything write to the fs if we
have anything wrong in extent tree.

Thanks,
Qu
>
> Ideally it should replay everything except extent refs. >
>
> I also noticed that after unmount there is:
>
> [11000.562504] BTRFS warning (device sde): page private not zero on
> page 21057098481664
> [11000.562510] BTRFS warning (device sde): page private not zero on
> page 21057098485760
>
> not sure what it means.
>
>
> Best regards,
> D=C4=81vis
>