Re: [PATCH 08/12] xfs: remove xfs_ifork_ops

Brian Foster
2020-05-07T13:44:02Z

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