Re: [PATCH] meson: wire up USE_NSEC build knob

[Jeff King <peff@peff.net>]

On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:

> Autotools-style builds permit enabling USE_NSEC for cases where that's
> desired; the equivalent knob is missing from meson-based builds.

Seems reasonable. This is not changing the defaults at all, but just
bringing meson's options to parity with the Makefile.

I'm not still not sure if turning on USE_NSEC is a good idea. There's
some discussion in Documentation/technical/racy-git.adoc:

  With `USE_NSEC`
  compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
  members are also compared. On Linux, this is not enabled by default
  because in-core timestamps can have finer granularity than
  on-disk timestamps, resulting in meaningless changes when an
  inode is evicted from the inode cache.  See commit 8ce13b0
  of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
  ([PATCH] Sync in core time granularity with filesystems,
  2005-01-04). This patch is included in kernel 2.6.11 and newer, but
  only fixes the issue for file systems with exactly 1 ns or 1 s
  resolution. Other file systems are still broken in current Linux
  kernels (e.g. CEPH, CIFS, NTFS, UDF), see
  https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/

That's the most succinct description of the problem I've seen, but I
have no idea how widely it still applies. Kernel 2.6.11 is quite old
now, but I could believe that other filesystems (especially network
ones) still exhibit the issue.

So I guess if we wanted to go further it would take some digging as to
how each platform behaves, and then flipping the config.make.uname knob
for ones where it can be argued that the behavior is always reasonable.

But that's all outside the scope of your patch here.

-Peff