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". Regards, - Ted
