On Tue, Feb 09, 2021 at 09:21:40PM -0500, Theodore Ts'o wrote: > On Tue, Feb 09, 2021 at 04:52:07PM -0800, Darrick J. Wong wrote: > > > > I definitely don't want to implement string parsing for xfs_scrub. > > > > The kernel already has enough information to fill out the struct > > xfs_scrub_metadata structure for userspace in case it decides to repair. > > I suspect anything which is specific enough for xfs_scrub is going to > be *significantly* file system dependent. And in the past, attempts > to do some kind of binary tag-length-value scheme has generally gotten > vetoed. If it's just "there's something wrong with inode number 42", > that's one thing. But if it's, "position 37 of the 3rd btree interior > node is out of order", how in the world is that supposed to be > generic? > > Taking a step back, it seems that there are a number of different use > cases that people have been discussing on this thread. One is > "there's something wrong with the file system", so the file system > should be taken off-line for repair and/or fail over the primary > server to the secondary/backup server. > > Yet another use case might be "the file system is getting full, so > please expand the LVM and resize the file system". (This is a bit > more complex since different system administrators and different > systems may want different trigger points, from 75%, 80%, 95%, or > "we've already delivered ENOSPC to the application so there are > user-visible failures", but presumably this can be configured, with > perhaps sime fixed number of configured trigger points per file > system.) > > Both of these are fairly generic, and don't required exposing a file > system's detailed, complex object hierarchies to userspace. But if > the goal is pushing out detailed metadata information sufficient for > on-line file system repair, that both seems to be a massive case of > scope creep, and very much file system specific, and not something > that could be easily made generic. > > If the XFS community believes it can be done, perhaps you or Dave > could come up with a specific proposal, as opposed to claiming that > Gabriel's design is inadequate because it doesn't meet with XFS's use > case? And perhaps this is a sufficiently different set of > requirements that it doesn't make sense to try to have a single design > that covers all possible uses of a "file system notification system". I did in [1], but vger is being slow and hasn't yet delivered it to me yet. At least they try to hit lore first now, I guess? --D [1] https://lore.kernel.org/linux-fsdevel/20210210000932.GH7190@magnolia/T/#m268c5a244cb7bd749b9c029e1d7c3f00d194b181 > Regards, > > - Ted
