On Thu, Jul 05, 2018 at 05:47:48PM -0700, Darrick J. Wong wrote: > On Thu, Jul 05, 2018 at 05:03:24PM +1000, Dave Chinner wrote: > > IOWs, ISTM that the online scrub/repair algorithms break down in the > > face of rmap corruption and it is correctable only by building a > > global cross-reference which we can then reconcile and use to > > rebuild all the per-AG metadata btrees in the filesystem. Trying to > > do it online via scanning of unverifiable structures risks making > > the problem worse and there is a good possibility that we can't > > repair the inconsistencies in a single pass. > > Yeah. I've pondered whether or not the primary repairers ought to > require at least a quick rmap scan before they touch anything, but up > till now I've preferred to keep that knowledge in xfs_scrub. I think that's fine - scrub is most likely going to be the trigger to run online repair, anyway. > > So at this point, I'd prefer that we stop, discuss and work out a > > solution to the rmap rebuild problem rather than merge a rmap > > rebuild algorithm prematurely. This doesn't need to hold up any of > > the other online repair functionality - none of that is dependent on > > this particular piece of the puzzle being implemented. > > I didn't think it would hold up the others repairers. I always knew > that the rmapbt repair was going to be a tough project. :) > > So, seeing as you're about to head off on vacation, let's set a rough > time to discuss the rmap rebuild problem in detail once you're back. > Does that sound good? Yes. Gives us some thinking time, too :P Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
