Re: [PATCH] xfs_scrub_all.timer: don't run if /var/lib/xfsprogs is readonly

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

On Wed, Jan 22, 2025 at 08:22:47AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 21, 2025 at 11:18:29PM -0800, Darrick J. Wong wrote:
> > Eh, it's mostly to shut up systems where even /var/lib is readonly.
> 
> What are those systems?  They must still provide some place writable
> for semi-persistant data, so we should look for that?

The particular place that I noticed this was on my fstests fleet, where
the root filesystem is an ro nfs4 export.  I forgot to configure an
overlayfs for /var/lib/xfsprogs, so when I upgraded it to xfsprogs 6.12
and left the VMs running on a Sunday morning, they tried to start
xfs_scrub_all and failed.  Then the monitoring systems emailed me about
that, and I got 150 emails. :(

This /should/ be a pretty uncommon situation since (AFAICT) most
readonly-root systems set up a writable (and possibly volatile)
/var/lib, but I thought I should just turn off the timer if it's going
to fail anyway.

> > IIRC systemd's volatile mode isn't quite that silly, but it'd be nice
> > to avoid xfs_scrub_all repeatedly failing every time the timer fires.
> > 
> > OTOH maybe a better solution is just to run scrub in media scan mode if
> > the media scan stamp file can't be opened for writing?
> 
> Or not run it at all?  Either way I'd like to understand what causes
> this.

<nod>

--D