All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 08/12] xfs: remove xfs_ifork_ops
Date: Thu, 7 May 2020 09:43:55 -0400	[thread overview]
Message-ID: <20200507134355.GF9003@bfoster> (raw)
In-Reply-To: <20200507123411.GB17936@lst.de>

On Thu, May 07, 2020 at 02:34:11PM +0200, Christoph Hellwig wrote:
> On Fri, May 01, 2020 at 02:23:16PM -0400, Brian Foster wrote:
> > Can we use another dummy parent inode value in xfs_repair? It looks to
> > me that we set it to zero in phase 4 if it fails verification and set
> > the parent to NULLFSINO (i.e. unknown) in repair's in-core tracking.
> > Phase 6 walks the directory entries and explicitly sets the parent inode
> > number of entries with an unknown parent (according to the in-core
> > tracking). IOW, I don't see where we actually rely on the directory
> > header having a parent inode of zero outside of detecting it in the
> > custom verifier. If that's the only functional purpose, I wonder if we
> > could do something like set the bogus parent field of a sf dir to the
> > root inode or to itself, that way the default verifier wouldn't trip
> > over it..
> 
> I don't think we need a dummy parent at all - we can just skip the
> parent validation entirely, which is what my incremental patch does.
> 

xfs_repair already skips the parent validation, this patch just
refactors it. What I was considering above is whether repair uses the
current dummy value of zero for any functional reason. If not, it kind
of looks like the earlier phase of repair checks the parent, sees that
it would fail a verifier, replaces it with zero (which would also fail
the verifier) and then eventually replaces zero with a valid parent or
ditches the entry in phase 6. If we placed a temporary parent value in
the early phase that wouldn't explicitly fail a verifier by being an
invalid inode number (instead of using 0 to notify the verifier to skip
the validation), then we wouldn't need to skip the parent validation in
phase 6 when we look up the inode again.

Brian


  reply	other threads:[~2020-05-07 13:44 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01  8:14 dinode reading cleanups Christoph Hellwig
2020-05-01  8:14 ` [PATCH 01/12] xfs: xfs_bmapi_read doesn't take a fork id as the last argument Christoph Hellwig
2020-05-01 13:33   ` Brian Foster
2020-05-01  8:14 ` [PATCH 02/12] xfs: call xfs_iformat_fork from xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:33   ` Brian Foster
2020-05-01  8:14 ` [PATCH 03/12] xfs: split xfs_iformat_fork Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-07 12:27     ` Christoph Hellwig
2020-05-07 13:40       ` Brian Foster
2020-05-07 13:42         ` Christoph Hellwig
2020-05-01  8:14 ` [PATCH 04/12] xfs: handle unallocated inodes in xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 05/12] xfs: call xfs_dinode_verify from xfs_inode_from_disk Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 06/12] xfs: don't reset i_delayed_blks in xfs_iread Christoph Hellwig
2020-05-01 13:34   ` Brian Foster
2020-05-01  8:14 ` [PATCH 07/12] xfs: remove xfs_iread Christoph Hellwig
2020-05-01 15:56   ` Brian Foster
2020-05-01  8:14 ` [PATCH 08/12] xfs: remove xfs_ifork_ops Christoph Hellwig
2020-05-01 15:56   ` Brian Foster
2020-05-01 16:08     ` Darrick J. Wong
2020-05-01 16:38       ` Christoph Hellwig
2020-05-01 16:50         ` Christoph Hellwig
2020-05-01 18:23           ` Brian Foster
2020-05-07 12:34             ` Christoph Hellwig
2020-05-07 13:43               ` Brian Foster [this message]
2020-05-07 16:28                 ` Brian Foster
2020-05-07 17:18                   ` Christoph Hellwig
2020-05-12 23:50                     ` Darrick J. Wong
2020-05-01  8:14 ` [PATCH 09/12] xfs: refactor xfs_inode_verify_forks Christoph Hellwig
2020-05-01 15:57   ` Brian Foster
2020-05-01 16:40     ` Christoph Hellwig
2020-05-01 17:02       ` Brian Foster
2020-05-01 17:08         ` Christoph Hellwig
2020-05-01  8:14 ` [PATCH 10/12] xfs: improve local fork verification Christoph Hellwig
2020-05-01  8:14 ` [PATCH 11/12] xfs: remove the special COW fork handling in xfs_bmapi_read Christoph Hellwig
2020-05-01 15:57   ` Brian Foster
2020-05-01  8:14 ` [PATCH 12/12] xfs: remove the NULL " Christoph Hellwig
2020-05-01 15:58   ` Brian Foster
2020-05-08  6:34 dinode reading cleanups v2 Christoph Hellwig
2020-05-08  6:34 ` [PATCH 08/12] xfs: remove xfs_ifork_ops Christoph Hellwig
2020-05-08 15:05   ` Brian Foster
2020-05-09  8:17     ` Christoph Hellwig
2020-05-09 11:13       ` Brian Foster
2020-05-16 17:48         ` Darrick J. Wong
2020-05-18 13:35           ` Brian Foster
2020-05-18 16:07             ` Darrick J. Wong

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=20200507134355.GF9003@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.