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
