Date: Fri, 10 Oct 2025 01:34:13 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dave Cottlehuber <dch@skunkwerks.at> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: getfsstat(2) MNT_NOWAIT & stale data for zpool Message-ID: <aOg4ZTt3DkqHjdad@kib.kiev.ua> In-Reply-To: <d9afa414-be12-4894-95f6-1c68186cbf73@app.fastmail.com> References: <2706a6b0-ef12-440d-9f29-da5b9e597f9b@app.fastmail.com> <aOal-ZA6K7OOAMsV@server.rulingia.com> <b156c2da-dfc6-4c8c-aa1c-ceeba716cc99@app.fastmail.com> <aOe-RVVopePjzNpf@kib.kiev.ua> <d9afa414-be12-4894-95f6-1c68186cbf73@app.fastmail.com>
index | next in thread | previous in thread | raw e-mail
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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aOg4ZTt3DkqHjdad>