Re: [PATCH 3/3] debian: enable xfs_scrub_all systemd timer services by default

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

On Wed, Jul 17, 2024 at 06:59:04AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 16, 2024 at 09:46:29AM -0700, Darrick J. Wong wrote:
> > Hm, xfs could do that, but that would clutter up the mount options.
> > Or perhaps the systemd service could look for $mountpoint/.autoheal or
> > something.
> > 
> > It might be easier still to split the packages, let me send an RFC of
> > what that looks like.
> 
> So I think the package split makes sense no matter what we do,
> but I really want a per file system choice and not a global one.

<nod> How might we do that?

1. touch $mnt/.selfheal to opt-in to online fsck?
2. touch $mnt/.noselfheal to opt-out?
3. attr -s system.selfheal to opt in?
4. attr -s system.noselfheal to opt out?
5. compat feature to opt-in
6. compat feature to opt-out?
7. filesystem property that we stuff in the metadir?

1-2 most resemble the old /.forcefsck knob, and systemd has
ConditionPathExists= that we could use to turn an xfs_scrub@<path>
service invocation into a nop.

3-4 don't clutter up the root filesystem with dotfiles, but then if we
ever reset the root directory then the selfheal property is lost.

5-6 might be my preferred way, but then I think I have to add a fsgeom
flag so that userspace can detect the selfheal preferences.

7 is a special snowflake currently :P

Other issues:

a. Are there really two bits that we might want to store in the *heal
attribute?

   00 == never allow online fsck at all
   01 == allow invocations of xfs_scrub but don't let xfs_scrub_all
         invoke it
   11 == allow all invocations of online fsck

and probably useless:

   10 == allow invocations of xfs_scrub only from xfs_scrub_all

b. Adding these knobs means more userspace code to manage them.  1-4 can
be done easily in xfs_admin, 5-8 involve a new ioctl and io/db code.

c. 1-4 can be lost if something torches the root directory.  Is that ok?
7 also has that problem, but as nobody's really designed a filesystem
properties feature, I don't know if that's acceptable.

> As a fіle system developer I always have scratch file systems around
> that I definitely never want checked.  I'd also prefer scrub to not
> randomly start checking external file system that are only temporarily
> mounted and that I want to remove again.

Another thing I need to figure out if systemd has a handy way of
terminating a service as a "prerequisite" to "stopping" a mount.
Right now you can unmount an fs that's being scrubbed from your mount
hierarchy, but the service keeps running and the mount is still
active.

> Maybe we'll indeed want some kind of marker in the file system.
> 
> Btw, the code in scrub_all that parses lsblk output to find file systems
> also looks a bit odd.  I'd expect it to use whatever is the python
> equivalent of setmntent/getmntent on /proc/self/mounts.

It parses the lsblk json output so that it can trace all the xfs mounts
back to raw block devices so that it can try to kick off as many scrubs
in parallel as it can so long as no two scrubs will hit the same bdev.

--D