Re: getfsstat(2) MNT_NOWAIT & stale data for zpool

On Thu, Oct 09, 2025 at 09:19:30PM +0000, Dave Cottlehuber wrote:
> On Thu, 9 Oct 2025, at 13:53, Konstantin Belousov wrote:
> > On Thu, Oct 09, 2025 at 07:23:02AM +0000, Dave Cottlehuber wrote:
> >> On Wed, 8 Oct 2025, at 17:57, Peter Jeremy wrote:
> >> > On 2025-Oct-08 15:59:12 +0000, Dave Cottlehuber <dch@skunkwerks.at> wrote:
> >> >>When does getfsstat(2) stale info get updated?
> >> >
> >> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273094 and 
> >> > https://github.com/prometheus/node_exporter/issues/1498
> >> >
> >> > -- 
> >> > Peter Jeremy
> >> 
> >> Hi Peter
> >> 
> >> Thanks these are very helpful. Looking at collectd which doesn't suffer
> >> from this issue, it uses a different libc function, to avoid this.
> >> 
> >> - call getfsstat(2) + MNT_NOWAIT to get a possibly stale list of filesystems
> >> - iterate over that list, but with statfs(2) which I assume doesn't use stale data (as there is no mention of MNT_(NO)WAIT type flags)
> >> 
> >> At least for the prometheus case, I can look into fixing that upstream.
> >> 
> >> Is there some historical context for this stale behaviour?
> >> 
> >> I assume in the days when people used UNIX as a multi-user system, this
> >> info would be continually refreshed by general user activity. But in
> >> a more server-centric / cloud approach this might not occur for hours.
> >
> > Purpose of MNT_NOWAIT flag is to avoid syscall blocking when networking
> > fs is blocked due to server unresponsibility. This is definitely the
> > case for NFS, and might be for things like smbfs or p9fs (not sure).
> 
> Yes it's clear why this flag exists for such fs.
> 
> But how & when does this stale information get updated normally? Is
> it only via the commands that touch mountpoints explicitly? Or are
> there some more common user patterns that can trigger it?

System does not consume VFS_STATFS info, it is only for user presentation.
So it is updated when something asks for it.