public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: bodonnel@redhat.com, linux-xfs@vger.kernel.org, aalbersh@kernel.org
Subject: Re: [PATCH v3] xfs_repair: fix link counts update following repair of a bad block
Date: Tue, 15 Apr 2025 18:30:12 -0700	[thread overview]
Message-ID: <20250416013012.GX25675@frogsfrogsfrogs> (raw)
In-Reply-To: <d20ee07d-bdcc-48b4-9e35-7228187d69e7@sandeen.net>

On Tue, Apr 15, 2025 at 02:12:31PM -0500, Eric Sandeen wrote:
> On 4/15/25 1:48 PM, 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,
> > to handle both longform and shortform directory cases. 
> 
> This is not accurate; short form directories are not generally in play here.
> They only arise due to the directory rebuild orphaning all entries without
> the prior scan, yielding an empty directory.
> 
> > 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.
> 
> Changelog suggestion:
> 
> xfs_repair: phase6: scan longform entries before header check
> 
> In longform_dir2_entry_check, if check_dir3_header() fails for v5
> metadata, we immediately go to out_fix: and try to rebuild the directory
> via longform_dir2_rebuild. But because we haven't yet called
> longform_dir2_entry_check_data, the *hashtab used to rebuild the
> directory is empty, which results in all existing entries getting
> moved to lost+found, and an empty rebuilt directory. On top of that,
> the empty directory is now short form, so its nlinks come out wrong
> and this requires another repair run to fix.
> 
> Scan the entries before checking the header, so that we have a decent
> chance of properly rebuilding the dir if the header is corrupt, rather
> than orphaning all the entries and moving them to lost+found.
> 
> > Suggested-by: Eric Sandeen <sandeen@sandeen.net>
> > 
> > Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
> 
> Other than the commit log, 
> 
> Reviewed-by: Eric Sandeen <sandeen@redhat.com>

With the changelog amended,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> 
> > ---
> > 
> > v3: fix logic to cover the shortform directory case, and fix the description
> > v2: attempt to cover the case where header indicates shortform directory
> > v1:
> > 
> > 
> > 
> >  repair/phase6.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/repair/phase6.c b/repair/phase6.c
> > index dbc090a54139..4a3fafab3522 100644
> > --- a/repair/phase6.c
> > +++ b/repair/phase6.c
> > @@ -2424,6 +2424,11 @@ longform_dir2_entry_check(
> >  			continue;
> >  		}
> >  
> > +		/* salvage any dirents that look ok */
> > +		longform_dir2_entry_check_data(mp, ip, num_illegal, need_dot,
> > +				irec, ino_offset, bp, hashtab,
> > +				&freetab, da_bno, fmt == XFS_DIR2_FMT_BLOCK);
> > +
> >  		/* check v5 metadata */
> >  		if (xfs_has_crc(mp)) {
> >  			error = check_dir3_header(mp, bp, ino);
> > @@ -2438,9 +2443,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);
> >  		if (fmt == XFS_DIR2_FMT_BLOCK)
> >  			break;
> >  
> 
> 

      reply	other threads:[~2025-04-16  1:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-15 18:48 [PATCH v3] xfs_repair: fix link counts update following repair of a bad block bodonnel
2025-04-15 19:12 ` Eric Sandeen
2025-04-16  1:30   ` Darrick J. Wong [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=20250416013012.GX25675@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=aalbersh@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