From nobody Thu Oct 9 22:34:13 2025 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cjPnG60QWz6CFSq for ; Thu, 09 Oct 2025 22:34:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cjPnG1qdYz3q10 for ; Thu, 09 Oct 2025 22:34:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 599MYDpR015767; Fri, 10 Oct 2025 01:34:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 599MYDpR015767 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 599MYD83015766; Fri, 10 Oct 2025 01:34:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Oct 2025 01:34:13 +0300 From: Konstantin Belousov To: Dave Cottlehuber Cc: freebsd-fs Subject: Re: getfsstat(2) MNT_NOWAIT & stale data for zpool Message-ID: References: <2706a6b0-ef12-440d-9f29-da5b9e597f9b@app.fastmail.com> List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cjPnG1qdYz3q10 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 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.