On Thu, May 07, 2020 at 07:18:57PM +0200, Christoph Hellwig wrote: > On Thu, May 07, 2020 at 12:28:46PM -0400, Brian Foster wrote: > > To demonstrate, I hacked on repair a bit using an fs with an > > intentionally corrupted shortform parent inode and had to make the > > following tweaks to work around the custom fork verifier. The > > ino_discovery checks were added because phases 3 and 4 toggle that flag > > such that the former clears the parent value in the inode, but the > > latter actually updates the external parent tracking. IOW, setting a > > "valid" inode in phase 3 would otherwise trick phase 4 into using it. > > I'd probably try to think of something cleaner for that issue if we were > > to take such an approach. > > Ok, so instead of clearing the parent we'll set it to a guaranteed good > value (the root ino). That could kill the workaround I had entirely. Seems reasonable to me, but someone should try it and see how xfs_repair reacts. I think it ought to be fine since it will detect the lack of a rootdir entry pointing to the damaged dir and move it to lost+found. --D
