Re: getfsstat(2) MNT_NOWAIT & stale data for zpool
Date: Thu, 09 Oct 2025 21:19:30 UTC
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? A+ Dave