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
