On Mon, Dec 11, 2023 at 09:36:46PM -0800, Christoph Hellwig wrote: > On Mon, Dec 11, 2023 at 12:04:58PM -0800, Darrick J. Wong wrote: > > > Otherwise I'm still a bit worried about the symlink pointing to ? > > > and suspect we need a clear and documented strategy for things that > > > can change data for applications before doing something like that. > > > > For a brief second I thought about adding another ZAPPED health flag, > > like I just did for the data/attr forks. Then I realized that for > > symbolic link targets this doesn't make sense because we've lost the > > target data so there's no extended recovery that can be applied. > > > > Unfortunately this leaves me stuck because targets are arbitrary null > > terminated strings, so there's no bulletproof way to communicate "target > > has been lost, do not try to follow this path" without risking that the > > same directory actually contains a file with that name. > > > > At this point, we can't even iget the dead symlink to find the parent > > pointers so we can delete the inode from the directory tree, so that's > > also not an option. > > Can't we have a zapped flag that: > > a) let's it pass the verifier > b) but returns -EIO on any non-scrub access? After spending an entire day trying to figure out another way to encode an empty symlink target that wouldn't trip existing verifiers and failing, I suppose I will add a new flag. XFS_SICK_INO_SYMLINK_ZAPPED and I'll add it to the list of persistable inode health flags when we do them all. --D
