Date: Thu, 09 Oct 2025 07:23:02 +0000 From: "Dave Cottlehuber" <dch@skunkwerks.at> To: "Peter Jeremy" <peterj@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: getfsstat(2) MNT_NOWAIT & stale data for zpool Message-ID: <b156c2da-dfc6-4c8c-aa1c-ceeba716cc99@app.fastmail.com> In-Reply-To: <aOal-ZA6K7OOAMsV@server.rulingia.com> References: <2706a6b0-ef12-440d-9f29-da5b9e597f9b@app.fastmail.com> <aOal-ZA6K7OOAMsV@server.rulingia.com>
index | next in thread | previous in thread | raw e-mail
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. A+ Davehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b156c2da-dfc6-4c8c-aa1c-ceeba716cc99>