On Wed, Oct 04, 2017 at 11:02:04AM -0700, Darrick J. Wong wrote: > On Wed, Oct 04, 2017 at 05:43:33PM +1100, Dave Chinner wrote: > > It seems to me that we're using the superblock 0 values as the > > golden master because it's a mounted filesystem, and then comparing > > everything else against it. Maybe we should at least check a couple > > of secondary superblocks to see that they match the primary > > superblock - that way we'll have some confidence that at least > > things like agcount, agblocks, dblocks, etc are valid before we go > > any further... > > xfs_scrub_superblock does check the secondary superblock geometry > against whatever's in mp->m_sb, which came from sb 0. /me smacks forehead The patch is even named "scrub the backup superblocks". Perhaps it didn't sink in because they are normally called "secondary superblocks". My bad.... > > BUt maybe all we need is comment in the overall scrub description - > > that we're pretty much assuming that sb 0 is intact because we write > > what is in memory back to it and so we can simply validate > > everything else against the primary superblock contents... > > Correct. Since scrub is run against a mounted live filesystem we assume > that the mount code fully validated sb 0 and therefore we can rely on it > not being wrong. > > If OTOH sb 0 *is* wrong then the admin is better off running xfs_repair > because there's too much whirring machinery to go changing fundamental > geometry. Yup, that makes sense. 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
