Re: [RFC] Filesystem error notifications proposal

["Darrick J. Wong" <djwong@kernel.org>]

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