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.