Date: Sun, 13 Aug 2023 05:45:12 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273094] getfsstat can return unexpectedly stale statfs data. Message-ID: <bug-273094-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273094 Bug ID: 273094 Summary: getfsstat can return unexpectedly stale statfs data. Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: peterj@FreeBSD.org getfsstat(2) states: >Normally mode should be specified as MNT_WAIT. If mode is set to >MNT_NOWAIT, getfsstat() will return the information it has available >without requesting an update from each file system. Having looked at getfsstat(..., MNT_NOWAIT) output over time, as well as rummaging around in the FreeBSD kernel sources, it seems that the cached da= ta is basically never updated under normal operations. This means that, unless something else (like df) invokes getfsstat(2) with MNT_WAIT or statfs(2), t= he reported data using MNT_NOWAIT will reflect the information from when the filesystem was created or mounted. This was a surprise to me: I would have expected that the information was updated fairly regularly - e.g. on TXG flushes for ZFS and on superblock flushes for UFS. IMO, this is a POLA violation and it presents a problem for monitoring tools that are tracking filesystem usage in order to alert on low free space or similar: * Specifying MNT_WAIT could result in the getfsstat(2) call blocking indefinitely if (e.g.) a NFS server isn't responding. * Specifying MNT_NOWAIT returns data that is stale to the extent of being meaningless. This behaviour has led to (e.g.) https://github.com/prometheus/node_exporter/issues/1498 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273094-227>