From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 3/3] fsck.gfs2: Clear bad indirect block pointers when bitmap meets expectations
Date: Thu, 7 Nov 2019 19:08:27 +0000 [thread overview]
Message-ID: <20191107190827.14169-3-anprice@redhat.com> (raw)
In-Reply-To: <20191107190827.14169-1-anprice@redhat.com>
This issue only occurs when an indirect pointer of a 'system' directory
points to an invalid block but the block's bitmap state is as expected.
If the block's state is not as expected, the corruption is fixed by an
earlier check.
In this scenario, pass1_check_metalist() checks the type of a block and
compares it with what it expected the indirect pointer to point to. If
there is a metadata mismatch a bad indirect pointer is reported but the
entire inode is considered invalid, causing it to be removed later, or
rebuilt in the case of protected structures such as the root inode.
This is heavy-handed and the right thing to do is to zero the indirect
block pointer.
Previously we had no access to the pointer block itself to update it in
pass1_check_metalist() but now that an iptr is passed in, it's just a
case of zeroing the pointer at the correct offset and marking the bh as
modified. This means that fsck.gfs2 can now fix bad indirect pointers of
the root directory without throwing away the entire directory tree.
Resolves: rhbz#1487726
Signed-off-by: Andrew Price <anprice@redhat.com>
---
gfs2/fsck/pass1.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/gfs2/fsck/pass1.c b/gfs2/fsck/pass1.c
index 9f211eb6..437ceeec 100644
--- a/gfs2/fsck/pass1.c
+++ b/gfs2/fsck/pass1.c
@@ -401,8 +401,15 @@ static int pass1_check_metalist(struct iptr iptr, struct gfs2_buffer_head **bh,
(unsigned long long)ip->i_di.di_num.no_addr,
(unsigned long long)block,
(unsigned long long)block, blktypedesc);
- brelse(nbh);
- return meta_skip_further;
+ if (query(_("Zero the indirect block pointer? (y/n) "))){
+ *iptr_ptr(iptr) = 0;
+ bmodified(iptr.ipt_bh);
+ *is_valid = 1;
+ return meta_skip_one;
+ } else {
+ brelse(nbh);
+ return meta_skip_further;
+ }
}
bc->indir_count++;
--
2.21.0
prev parent reply other threads:[~2019-11-07 19:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 19:08 [Cluster-devel] [PATCH 1/3] fsck.gfs2: Fix segfault in build_and_check_metalist Andrew Price
2019-11-07 19:08 ` [Cluster-devel] [PATCH 2/3] fsck.gfs2: Retain context for indirect pointers in ->check_metalist Andrew Price
2019-11-07 19:08 ` Andrew Price [this message]
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=20191107190827.14169-3-anprice@redhat.com \
--to=anprice@redhat.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;
as well as URLs for NNTP newsgroup(s).