On Fri, Jul 02, 2021 at 08:02:33PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > While running xfs/168, I noticed a second source of post-shrink > corruption errors causing shutdowns. > > Let's say that directory B has a low inode number and is a child of > directory A, which has a high number. If B is empty but open, and > unlinked from A, B's dotdot link continues to point to A. If A is then > unlinked and the filesystem shrunk so that A is no longer a valid inode, > a subsequent AIL push of B will trip the inode verifiers because the > dotdot entry points outside of the filesystem. So we have a directory inode that is empty and unlinked but held open, with a back pointer to an invalid inode number? Which can never be followed, because the directory has been unlinked. Can't this be handled in the inode verifier? This seems to me to be a pretty clear cut case where the ".." back pointer should always be considered invalid (because the parent dir has no existence guarantee once the child has been removed from it), not just in the situation where the filesystem has been shrunk... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx