Re: [PATCH 01/11] docs: discuss autonomous self healing in the xfs online repair design doc

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

On Wed, Jan 07, 2026 at 10:08:44AM +0100, Christoph Hellwig wrote:
> On Mon, Jan 05, 2026 at 11:10:52PM -0800, Darrick J. Wong wrote:
> > +The filesystem must therefore create event objects in response to stimuli
> > +(metadata corruption, file I/O errors, etc.) and dispatch these events to
> > +downstream consumers.
> > +Downstream consumers that are in the kernel itself are easy to implement with
> > +the ``xfs_hooks`` infrastructure created for other parts of online repair; these
> > +are basically indirect function calls.
> 
> These hooks mostly went away, didn't they?

They completely went away now that there's only one possible healer
instance per mount and direct function calls.  I'll delete the sentence.

> > +Being private gives the kernel and ``xfs_healer`` the flexibility to change
> > +or update the event format in the future without worrying about backwards
> > +compatibility.
> 
> I think that ship has sailed once the ABI is out in the wild.

Yeah.  Once that's happened, the strongest argument is that we can
define our own formats without being subject to any of fsnotify's event
size constraints, and (more importantly) not needing to clutter up
fanotify's UABI with xfs-specific structures.  How about:

"Using a pseudofile gives the kernel and xfs_healer the flexibility to
expose xfs-specific filesystem details without cluttering up fanotify's
userspace ABI.
Normal userspace programs are not expected to subscribe to these events."

> This whole why not use XYZ discussion seems vaguely interesting for a
> commit log, but does it belong into the main documentation?

That's an interesting philosophical question that Allison brought up
during review of this same document years ago.  I chose to leave these
Q&A's about the road not travelled in the doc because people keep
bringing then up, and I think it's useful to present that.

I left them as a separate Q&A sidebar to make it a little more obvious
that it's a sidebar.

> > +*Answer*: Yes.
> > +fanotify is much more careful about filtering out events to processes that
> > +aren't running with privileges.
> > +These processes should have a means to receive simple notifications about
> > +file errors.
> > +However, this will require coordination between fanotify, ext4, and XFS, and
> > +is (for now) outside the scope of this project.
> 
> Didn't this already get merged by Christian, and thus this information
> is stale already?

I'm not sure.  brauner said he merged it, but I haven't seen it show up
in vfs.all or anywhere else in vfs.git.  I asked him about the status
yesterday:

https://lore.kernel.org/linux-fsdevel/176602332085.686273.7564676516217176769.stgit@frogsfrogsfrogs/T/#mb00d485a7a146529c1bb022217d56ead50811162

but have not yet received a reply.

> > +When a filesystem mounts, the Linux kernel initiates a uevent describing the
> > +mount and the path to the data device.
> 
> This also isn't true anymore, is it?

Oh yes very much not true anymore.

"When a filesystem is mounted, the kernel initiates a fsnotify event
describing the mount point and path to the data device.
A separate systemd service will listen for these mount events via
fanotify, and can start a mount-specific xfs_healer service instance."

--D