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

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).