From: "Darrick J. Wong" <djwong@kernel.org>
To: bodonnel@redhat.com
Cc: linux-xfs@vger.kernel.org, sandeen@sandeen.net
Subject: Re: [PATCH v2] xfs_repair: fix link counts update following repair of a bad block
Date: Tue, 15 Apr 2025 10:07:57 -0700 [thread overview]
Message-ID: <20250415170757.GT25675@frogsfrogsfrogs> (raw)
In-Reply-To: <20250415150103.63316-2-bodonnel@redhat.com>
On Tue, Apr 15, 2025 at 10:01:04AM -0500, bodonnel@redhat.com wrote:
> From: Bill O'Donnell <bodonnel@redhat.com>
>
> Updating nlinks, following repair of a bad block needs a bit of work.
> In unique cases, 2 runs of xfs_repair is needed to adjust the count to
> the proper value. This patch modifies location of longform_dir2_entry_check,
> moving longform_dir2_entry_check_data to run after the check_dir3_header
> error check. This results in the hashtab to be correctly filled and those
> entries don't end up in lost+found, and nlinks is properly adjusted on the
> first xfs_repair pass.
>
> Suggested-by: Eric Sandeen <sandeen@sandeen.net>
>
> Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
> ---
> v2: add logic to cover shortform directory.
>
>
> repair/phase6.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/repair/phase6.c b/repair/phase6.c
> index dbc090a54139..8fc1c3896d2b 100644
> --- a/repair/phase6.c
> +++ b/repair/phase6.c
> @@ -2426,6 +2426,23 @@ longform_dir2_entry_check(
>
> /* check v5 metadata */
> if (xfs_has_crc(mp)) {
> + longform_dir2_entry_check_data(mp, ip, num_illegal,
> + need_dot,
> + irec, ino_offset, bp, hashtab,
> + &freetab, da_bno, fmt == XFS_DIR2_FMT_BLOCK);
> + error = check_dir3_header(mp, bp, ino);
> + if (error) {
> + fixit++;
I think what you're trying to do here is to get
longform_dir2_entry_check_data to try to find directory entries in the
directory block (no matter how damaged it is). Then if the dir3 header
fields are wrong, we bump fixit so that the directory gets rebuilt from
the salvaged directory entries. Right?
So I think you could structure this more like:
/* salvage any dirents that look ok */
longform_dir2_entry_check_data(...);
/* check v5 metadata */
if (xfs_has_crc(mp)) {
error = check_dir3_header(mp, bp, ino);
if (error) {
fixit++;
if (fmt == XFS_DIR2_FMT_BLOCK)
goto out_fix;
libxfs_buf_relse(bp);
bp = NULL;
continue;
}
}
if (fmt == XFS_DIR2_FMT_BLOCK)
break;
libxfs_buf_relse(bp);
bp = NULL;
}
> + if (fmt == XFS_DIR2_FMT_BLOCK)
> + goto out_fix;
> +
> + libxfs_buf_relse(bp);
> + bp = NULL;
> + continue;
> + }
> + }
> + else {
> + /* No crc. Directory appears to be shortform. */
> error = check_dir3_header(mp, bp, ino);
dir3 headers (as opposed to dir2 headers) are a crc-only feature, so
this isn't correct either.
> if (error) {
> fixit++;
> @@ -2438,9 +2455,6 @@ longform_dir2_entry_check(
> }
> }
>
> - longform_dir2_entry_check_data(mp, ip, num_illegal, need_dot,
> - irec, ino_offset, bp, hashtab,
> - &freetab, da_bno, fmt == XFS_DIR2_FMT_BLOCK);
and removing this call means that we never scan a V4 directory at all.
--D
> if (fmt == XFS_DIR2_FMT_BLOCK)
> break;
>
> --
> 2.49.0
>
>
next prev parent reply other threads:[~2025-04-15 17:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 15:01 [PATCH v2] xfs_repair: fix link counts update following repair of a bad block bodonnel
2025-04-15 17:07 ` Darrick J. Wong [this message]
2025-04-15 17:17 ` Bill O'Donnell
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=20250415170757.GT25675@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bodonnel@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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