From: "Dāvis Mosāns" <davispuh@gmail.com>
To: 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>
Subject: Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree
Date: Wed, 17 Mar 2021 03:29:24 +0200 [thread overview]
Message-ID: <CAOE4rSwj9_DMWLszPE5adiTsQeK+G_Hqya_HkDR=uEC7L4Fj3A@mail.gmail.com> (raw)
In-Reply-To: <20210317012054.238334-1-davispuh@gmail.com>
trešd., 2021. g. 17. marts, plkst. 03:18 — lietotājs Dāvis Mosāns
(<davispuh@gmail.com>) rakstīja:
>
> 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āvis Mosāns <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 = check_chunk_block_group_mappings(info);
> error:
> btrfs_free_path(path);
> +
> + if (ret == -EIO && btrfs_test_opt(info, IGNOREBADROOTS)) {
> + btrfs_put_block_group_cache(info);
> + btrfs_stop_all_workers(info);
> + btrfs_free_block_groups(info);
> + ret = btrfs_init_workqueues(info, NULL);
> + if (ret)
> + return ret;
> + ret = btrfs_init_space_info(info);
> + if (ret)
> + return ret;
> + return fill_dummy_bgs(info);
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=-5 IO failure
[ 1398.218828] BTRFS: error (device sde) in
btrfs_run_delayed_refs:2124: errno=-5 IO failure
[ 1398.219002] BTRFS: error (device sde) in btrfs_replay_log:2254:
errno=-5 IO failure (Failed to recover log tree)
[ 1398.229048] BTRFS error (device sde): open_ctree failed
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āvis
next prev parent reply other threads:[~2021-03-17 1:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 1:20 [RFC] btrfs: Allow read-only mount with corrupted extent tree Dāvis Mosāns
2021-03-17 1:29 ` Dāvis Mosāns [this message]
2021-03-17 10:28 ` Qu Wenruo
2021-03-17 21:03 ` Dāvis Mosāns
2021-03-17 23:49 ` Qu Wenruo
2021-03-19 15:34 ` Dāvis Mosāns
2021-03-20 0:34 ` Qu Wenruo
2021-03-21 21:49 ` [PATCH] " Dāvis Mosāns
2021-04-21 16:00 ` Dāvis Mosāns
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='CAOE4rSwj9_DMWLszPE5adiTsQeK+G_Hqya_HkDR=uEC7L4Fj3A@mail.gmail.com' \
--to=davispuh@gmail.com \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).