[PATCH] meson: wire up USE_NSEC build knob

[PATCH] meson: wire up USE_NSEC build knob

[D. Ben Knoble]

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

Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
---
 meson.build       | 4 ++++
 meson_options.txt | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/meson.build b/meson.build
index 3247697f74..85a11119c5 100644
--- a/meson.build
+++ b/meson.build
@@ -838,6 +838,10 @@ if help_format_opt != 'man'
     libgit_c_args += '-DDEFAULT_HELP_FORMAT="' + help_format_opt + '"'
 endif
 
+if get_option('nanosec')
+  libgit_c_args += '-DUSE_NSEC'
+endif
+
 libgit_include_directories = [ '.' ]
 libgit_dependencies = [ ]
 
diff --git a/meson_options.txt b/meson_options.txt
index d936ada098..1bc75278a8 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -21,6 +21,8 @@ option('runtime_prefix', type: 'boolean', value: false,
   description: 'Resolve ancillary tooling and support files relative to the location of the runtime binary instead of hard-coding them into the binary.')
 option('sane_tool_path', type: 'array', value: [],
   description: 'An array of paths to pick up tools from in case the normal tools are broken or lacking.')
+option('nanosec', type: 'boolean', value: false,
+  description: 'Care about sub-second file mtimes and ctimes.')
 
 # Build information compiled into Git and other parts like documentation.
 option('build_date', type: 'string', value: '',

base-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347
-- 
2.55.0.rc0.738.g0c8ab3ebcc.dirty

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

[Junio C Hamano]

"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:

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

With or without autoconf, Makefile based build can use USE_NSEC.  It
is a welcome addition to the other side of thw world.  I do not know
if 'meson setup -Dnanosec=true' is a name that is easy to discover,
though.

Will queue.  Thanks.

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

[D. Ben Knoble]

On Sat, Jun 20, 2026 at 9:01 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
>
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
>
> With or without autoconf, Makefile based build can use USE_NSEC.

Thanks. I almost wrote "Make-based," but I wasn't sure how we
preferred to describe it.

> It
> is a welcome addition to the other side of thw world.  I do not know
> if 'meson setup -Dnanosec=true' is a name that is easy to discover,
> though.
>
> Will queue.  Thanks.

Agreed for the name. Alternatives welcome.

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

[Jeff King]

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

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

[Patrick Steinhardt]

On Sat, Jun 20, 2026 at 06:01:25PM -0700, Junio C Hamano wrote:
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> 
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
> 
> With or without autoconf, Makefile based build can use USE_NSEC.  It
> is a welcome addition to the other side of thw world.  I do not know
> if 'meson setup -Dnanosec=true' is a name that is easy to discover,
> though.

I think the name itself is fine. As is the case for other options, it
can be discovered rather easily by just running `meson setup` in the
source directory, which gives you an overview of all available build
options.

Patrick

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

[Patrick Steinhardt]

On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:
> 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 was originally wondering whether I should recommend that Meson can
auto-discover the availability of nanoseconds. But your below remarks
make me question that.

> 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.

Yeah, it would be nice indeed to figure out whether these concerns still
apply. If they do, I would argue that it might even make sense to remove
the build option completely. It doesn't really make sense in my opinion
to have a build option that nobody uses and that is subtly broken when
enabled.

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

Kind of, I guess. If we figure that this mechanism is still subtly broken
then I'd argue that it doesn't make sense to expose the option via
Meson.

Patrick

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

[Jeff King]

On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:

> > 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.
> 
> Yeah, it would be nice indeed to figure out whether these concerns still
> apply. If they do, I would argue that it might even make sense to remove
> the build option completely. It doesn't really make sense in my opinion
> to have a build option that nobody uses and that is subtly broken when
> enabled.

I suspect it works just fine on some platforms and some filesystems
(i.e., those that actually store nanoseconds on disk). So probably Linux
with ext4 is OK. That's just guessing, though.

If I understand the original problem correctly, then doing this:

  touch foo
  ls --full-time foo
  echo 3 | sudo tee /proc/sys/vm/drop_caches
  ls --full-time foo

should be instructive. If it shows the same time for both "ls" calls,
then USE_NSEC would be fine. If it doesn't, then the system is losing
the nanosecond information when it drops the cache and has to reload
from disk (and thus USE_NSEC would cause spurious stat mismatches).

On my ext4 system, I get the same answers. So far so good.

I get the same answers with a loopback-mounted ext2 system. Which
surprised me a bit, but even unmounting and remounting the filesystem,
the nanosecond times are still there. So...I guess ext2 supports
nanoseconds.

I tried with a vfat mount, and it also works: we don't have nanoseconds
either before or after. That makes sense, and implies that modern Linux
will always be OK (because it limits the cached VFS response to what the
underlying filesystem can handle).

So...maybe this is just a non-issue these days, at least on Linux?

> > But that's all outside the scope of your patch here.
> 
> Kind of, I guess. If we figure that this mechanism is still subtly broken
> then I'd argue that it doesn't make sense to expose the option via
> Meson.

True, but AFAICT it probably is safe these days, at least one some
platforms.

-Peff

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

[Jeff King]

On Sun, Jun 28, 2026 at 04:18:07AM -0400, Jeff King wrote:

> I tried with a vfat mount, and it also works: we don't have nanoseconds
> either before or after. That makes sense, and implies that modern Linux
> will always be OK (because it limits the cached VFS response to what the
> underlying filesystem can handle).
> 
> So...maybe this is just a non-issue these days, at least on Linux?

Oh, I also ran across this old thread:

  https://public-inbox.org/git/5605D88A.20104%40gmail.com/

that implies similar:

  * In-core file times may not be properly rounded to on-disk
    precision, causing spurious file time changes when the cache is
    refreshed from disk. This was fixed for typical Unix file systems
    in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will
    be in kernel 4.3. There's no fix for FAT-based file systems yet.

I also tested with CIFS on my system and it is fine. It looks like FAT
systems were fixed since 2015. ;)

But there is another interesting question raised there, which is how
different implementations may interact (e.g., two versions of Git
without and without USE_NSEC, or JGit which may have to use
millisecond-resolution APIs, etc). It should all work correctly as long
as each implementation consistently uses its own resolution (so JGit
would have to compare in millisecond-space and treat ties as racy). And
I think that is _probably_ what is happening now, since we already store
nanoseconds unconditionally (and only use them with USE_NSEC).

Though the opposite case is a performance problem but not a correctness
one: if JGit writes out an index with milliseconds and USE_NSEC Git
tries to read it, we will consider everything stat-dirty and re-read the
contents.

I don't know if these would be a problem in practice or not, but it's an
interesting potential gotcha. And one that nobody may have noticed,
because probably hardly anybody bothers to build with USE_NSEC now.

-Peff

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On 2026-06-28 at 08:48:15, Jeff King wrote:
> Oh, I also ran across this old thread:
> 
>   https://public-inbox.org/git/5605D88A.20104%40gmail.com/
> 
> that implies similar:
> 
>   * In-core file times may not be properly rounded to on-disk
>     precision, causing spurious file time changes when the cache is
>     refreshed from disk. This was fixed for typical Unix file systems
>     in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will
>     be in kernel 4.3. There's no fix for FAT-based file systems yet.
> 
> I also tested with CIFS on my system and it is fine. It looks like FAT
> systems were fixed since 2015. ;)
> 
> But there is another interesting question raised there, which is how
> different implementations may interact (e.g., two versions of Git
> without and without USE_NSEC, or JGit which may have to use
> millisecond-resolution APIs, etc). It should all work correctly as long
> as each implementation consistently uses its own resolution (so JGit
> would have to compare in millisecond-space and treat ties as racy). And
> I think that is _probably_ what is happening now, since we already store
> nanoseconds unconditionally (and only use them with USE_NSEC).
> 
> Though the opposite case is a performance problem but not a correctness
> one: if JGit writes out an index with milliseconds and USE_NSEC Git
> tries to read it, we will consider everything stat-dirty and re-read the
> contents.
> 
> I don't know if these would be a problem in practice or not, but it's an
> interesting potential gotcha. And one that nobody may have noticed,
> because probably hardly anybody bothers to build with USE_NSEC now.

I would suggest that we provide a config knob and then build with
USE_NSEC by default.  Most people are using Linux with typical Unix file
systems, NTFS, CIFS, or FUSE (e.g., sshfs).  In the event someone
detects a problem, there's an easy solution—adjust the knob—and we can
then add a Linux-specific statfs call to determine if the file system is
a safe one in a future version.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

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

[Patrick Steinhardt]

On Sun, Jun 28, 2026 at 04:18:06AM -0400, Jeff King wrote:
> On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:
> 
> > > 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.
> > 
> > Yeah, it would be nice indeed to figure out whether these concerns still
> > apply. If they do, I would argue that it might even make sense to remove
> > the build option completely. It doesn't really make sense in my opinion
> > to have a build option that nobody uses and that is subtly broken when
> > enabled.
> 
> I suspect it works just fine on some platforms and some filesystems
> (i.e., those that actually store nanoseconds on disk). So probably Linux
> with ext4 is OK. That's just guessing, though.
> 
> If I understand the original problem correctly, then doing this:
> 
>   touch foo
>   ls --full-time foo
>   echo 3 | sudo tee /proc/sys/vm/drop_caches
>   ls --full-time foo
> 
> should be instructive. If it shows the same time for both "ls" calls,
> then USE_NSEC would be fine. If it doesn't, then the system is losing
> the nanosecond information when it drops the cache and has to reload
> from disk (and thus USE_NSEC would cause spurious stat mismatches).
> 
> On my ext4 system, I get the same answers. So far so good.
> 
> I get the same answers with a loopback-mounted ext2 system. Which
> surprised me a bit, but even unmounting and remounting the filesystem,
> the nanosecond times are still there. So...I guess ext2 supports
> nanoseconds.
> 
> I tried with a vfat mount, and it also works: we don't have nanoseconds
> either before or after. That makes sense, and implies that modern Linux
> will always be OK (because it limits the cached VFS response to what the
> underlying filesystem can handle).
> 
> So...maybe this is just a non-issue these days, at least on Linux?
> 
> > > But that's all outside the scope of your patch here.
> > 
> > Kind of, I guess. If we figure that this mechanism is still subtly broken
> > then I'd argue that it doesn't make sense to expose the option via
> > Meson.
> 
> True, but AFAICT it probably is safe these days, at least one some
> platforms.

Hm. That makes me wonder whether it is the completely wrong approach to
make this a build option then. If it works on some systems and only on
some filesystems, then a build option is just too coarse-grained. A
distro wouldn't really be able to ever enable the option, unless it knew
that repositories will only ever exist on a filesystem that works. Which
I guess is an assumption that no distro can make.

So instead, I wonder whether we should treat this the same as for
example "core.ignoreCase", where we only use nanosecond resolution when
opted in by the user. Ideally, if we had a way to detect brokenness, we
could even make git-init(1) set it automatically.

If so, we could unconditionally enable nanoseconds on platforms that
support them, but still have a runtime toggle for filesystems that
don't.

Patrick