[Bug 273094] getfsstat can return unexpectedly stale statfs data.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273094

            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 data
is basically never updated under normal operations.  This means that, unless
something else (like df) invokes getfsstat(2) with MNT_WAIT or statfs(2), the
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

-- 
You are receiving this mail because:
You are the assignee for the bug.