{"thread":{"id":"65848","subject":"[PATCH] meson: wire up USE_NSEC build knob","startedAt":"2026-06-20T16:00:48Z","lastAt":"2026-07-13T22:17:51Z","messageCount":19,"participants":["D. Ben Knoble","Junio C Hamano","Jeff King","Patrick Steinhardt","brian m. carlson","Ben Knoble"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"546037","messageId":"c4c5ade901ff95b0f95939ea818870e4f3d59da1.1781971201.git.ben.knoble+github@gmail.com","threadId":"65848","inReplyTo":null,"subject":"[PATCH] meson: wire up USE_NSEC build knob","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-06-20T16:00:24Z","receivedAt":"2026-06-20T16:00:48Z","isPatch":true,"body":"Autotools-style builds permit enabling USE_NSEC for cases where that's\ndesired; the equivalent knob is missing from meson-based builds.\n\nSigned-off-by: D. Ben Knoble \n---\n meson.build | 4 ++++\n meson_options.txt | 2 ++\n 2 files changed, 6 insertions(+)\n\ndiff --git a/meson.build b/meson.build\nindex 3247697f74..85a11119c5 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -838,6 +838,10 @@ if help_format_opt != 'man'\n libgit_c_args += '-DDEFAULT_HELP_FORMAT=\"' + help_format_opt + '\"'\n endif\n \n+if get_option('nanosec')\n+ libgit_c_args += '-DUSE_NSEC'\n+endif\n+\n libgit_include_directories = [ '.' ]\n libgit_dependencies = [ ]\n \ndiff --git a/meson_options.txt b/meson_options.txt\nindex d936ada098..1bc75278a8 100644\n--- a/meson_options.txt\n+++ b/meson_options.txt\n@@ -21,6 +21,8 @@ option('runtime_prefix', type: 'boolean', value: false,\n description: 'Resolve ancillary tooling and support files relative to the location of the runtime binary instead of hard-coding them into the binary.')\n option('sane_tool_path', type: 'array', value: [],\n description: 'An array of paths to pick up tools from in case the normal tools are broken or lacking.')\n+option('nanosec', type: 'boolean', value: false,\n+ description: 'Care about sub-second file mtimes and ctimes.')\n \n # Build information compiled into Git and other parts like documentation.\n option('build_date', type: 'string', value: '',\n\nbase-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347\n-- \n2.55.0.rc0.738.g0c8ab3ebcc.dirty\n\n"},{"id":"546047","messageId":"xmqq5x3cg10a.fsf@gitster.g","threadId":"65848","inReplyTo":"c4c5ade901ff95b0f95939ea818870e4f3d59da1.1781971201.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-21T01:01:25Z","receivedAt":"2026-06-21T01:01:28Z","isPatch":true,"body":"\"D. Ben Knoble\" writes:\n\n> Autotools-style builds permit enabling USE_NSEC for cases where that's\n> desired; the equivalent knob is missing from meson-based builds.\n\nWith or without autoconf, Makefile based build can use USE_NSEC. It\nis a welcome addition to the other side of thw world. I do not know\nif 'meson setup -Dnanosec=true' is a name that is easy to discover,\nthough.\n\nWill queue. Thanks.\n"},{"id":"546078","messageId":"CALnO6CADk607yWsN8b5r_mB5Hg4rm0m42YxsHfMSgzhOLayhfw@mail.gmail.com","threadId":"65848","inReplyTo":"xmqq5x3cg10a.fsf@gitster.g","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-06-21T16:41:29Z","receivedAt":"2026-06-21T16:41:41Z","isPatch":true,"body":"On Sat, Jun 20, 2026 at 9:01 PM Junio C Hamano wrote:\n>\n> \"D. Ben Knoble\" writes:\n>\n> > Autotools-style builds permit enabling USE_NSEC for cases where that's\n> > desired; the equivalent knob is missing from meson-based builds.\n>\n> With or without autoconf, Makefile based build can use USE_NSEC.\n\nThanks. I almost wrote \"Make-based,\" but I wasn't sure how we\npreferred to describe it.\n\n> It\n> is a welcome addition to the other side of thw world. I do not know\n> if 'meson setup -Dnanosec=true' is a name that is easy to discover,\n> though.\n>\n> Will queue. Thanks.\n\nAgreed for the name. Alternatives welcome.\n"},{"id":"546082","messageId":"20260621174934.GC2206349@coredump.intra.peff.net","threadId":"65848","inReplyTo":"c4c5ade901ff95b0f95939ea818870e4f3d59da1.1781971201.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-21T17:49:34Z","receivedAt":"2026-06-21T17:49:35Z","isPatch":true,"body":"On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:\n\n> Autotools-style builds permit enabling USE_NSEC for cases where that's\n> desired; the equivalent knob is missing from meson-based builds.\n\nSeems reasonable. This is not changing the defaults at all, but just\nbringing meson's options to parity with the Makefile.\n\nI'm not still not sure if turning on USE_NSEC is a good idea. There's\nsome discussion in Documentation/technical/racy-git.adoc:\n\n With `USE_NSEC`\n compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`\n members are also compared. On Linux, this is not enabled by default\n because in-core timestamps can have finer granularity than\n on-disk timestamps, resulting in meaningless changes when an\n inode is evicted from the inode cache. See commit 8ce13b0\n of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git\n ([PATCH] Sync in core time granularity with filesystems,\n 2005-01-04). This patch is included in kernel 2.6.11 and newer, but\n only fixes the issue for file systems with exactly 1 ns or 1 s\n resolution. Other file systems are still broken in current Linux\n kernels (e.g. CEPH, CIFS, NTFS, UDF), see\n https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/\n\nThat's the most succinct description of the problem I've seen, but I\nhave no idea how widely it still applies. Kernel 2.6.11 is quite old\nnow, but I could believe that other filesystems (especially network\nones) still exhibit the issue.\n\nSo I guess if we wanted to go further it would take some digging as to\nhow each platform behaves, and then flipping the config.make.uname knob\nfor ones where it can be argued that the behavior is always reasonable.\n\nBut that's all outside the scope of your patch here.\n\n-Peff\n"},{"id":"546119","messageId":"ajjum9Cf78N-VCH1@pks.im","threadId":"65848","inReplyTo":"xmqq5x3cg10a.fsf@gitster.g","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-22T08:13:15Z","receivedAt":"2026-06-22T08:13:23Z","isPatch":true,"body":"On Sat, Jun 20, 2026 at 06:01:25PM -0700, Junio C Hamano wrote:\n> \"D. Ben Knoble\" writes:\n> \n> > Autotools-style builds permit enabling USE_NSEC for cases where that's\n> > desired; the equivalent knob is missing from meson-based builds.\n> \n> With or without autoconf, Makefile based build can use USE_NSEC. It\n> is a welcome addition to the other side of thw world. I do not know\n> if 'meson setup -Dnanosec=true' is a name that is easy to discover,\n> though.\n\nI think the name itself is fine. As is the case for other options, it\ncan be discovered rather easily by just running `meson setup` in the\nsource directory, which gives you an overview of all available build\noptions.\n\nPatrick\n"},{"id":"546120","messageId":"ajjuoS5Qc3K0nCRl@pks.im","threadId":"65848","inReplyTo":"20260621174934.GC2206349@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-22T08:13:21Z","receivedAt":"2026-06-22T08:13:27Z","isPatch":true,"body":"On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:\n> On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:\n> \n> > Autotools-style builds permit enabling USE_NSEC for cases where that's\n> > desired; the equivalent knob is missing from meson-based builds.\n> \n> Seems reasonable. This is not changing the defaults at all, but just\n> bringing meson's options to parity with the Makefile.\n\nI was originally wondering whether I should recommend that Meson can\nauto-discover the availability of nanoseconds. But your below remarks\nmake me question that.\n\n> I'm not still not sure if turning on USE_NSEC is a good idea. There's\n> some discussion in Documentation/technical/racy-git.adoc:\n> \n> With `USE_NSEC`\n> compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`\n> members are also compared. On Linux, this is not enabled by default\n> because in-core timestamps can have finer granularity than\n> on-disk timestamps, resulting in meaningless changes when an\n> inode is evicted from the inode cache. See commit 8ce13b0\n> of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git\n> ([PATCH] Sync in core time granularity with filesystems,\n> 2005-01-04). This patch is included in kernel 2.6.11 and newer, but\n> only fixes the issue for file systems with exactly 1 ns or 1 s\n> resolution. Other file systems are still broken in current Linux\n> kernels (e.g. CEPH, CIFS, NTFS, UDF), see\n> https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/\n> \n> That's the most succinct description of the problem I've seen, but I\n> have no idea how widely it still applies. Kernel 2.6.11 is quite old\n> now, but I could believe that other filesystems (especially network\n> ones) still exhibit the issue.\n> \n> So I guess if we wanted to go further it would take some digging as to\n> how each platform behaves, and then flipping the config.make.uname knob\n> for ones where it can be argued that the behavior is always reasonable.\n\nYeah, it would be nice indeed to figure out whether these concerns still\napply. If they do, I would argue that it might even make sense to remove\nthe build option completely. It doesn't really make sense in my opinion\nto have a build option that nobody uses and that is subtly broken when\nenabled.\n\n> But that's all outside the scope of your patch here.\n\nKind of, I guess. If we figure that this mechanism is still subtly broken\nthen I'd argue that it doesn't make sense to expose the option via\nMeson.\n\nPatrick\n"},{"id":"546587","messageId":"20260628081806.GA3594700@coredump.intra.peff.net","threadId":"65848","inReplyTo":"ajjuoS5Qc3K0nCRl@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-28T08:18:06Z","receivedAt":"2026-06-28T08:18:08Z","isPatch":true,"body":"On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:\n\n> > So I guess if we wanted to go further it would take some digging as to\n> > how each platform behaves, and then flipping the config.make.uname knob\n> > for ones where it can be argued that the behavior is always reasonable.\n> \n> Yeah, it would be nice indeed to figure out whether these concerns still\n> apply. If they do, I would argue that it might even make sense to remove\n> the build option completely. It doesn't really make sense in my opinion\n> to have a build option that nobody uses and that is subtly broken when\n> enabled.\n\nI suspect it works just fine on some platforms and some filesystems\n(i.e., those that actually store nanoseconds on disk). So probably Linux\nwith ext4 is OK. That's just guessing, though.\n\nIf I understand the original problem correctly, then doing this:\n\n touch foo\n ls --full-time foo\n echo 3 | sudo tee /proc/sys/vm/drop_caches\n ls --full-time foo\n\nshould be instructive. If it shows the same time for both \"ls\" calls,\nthen USE_NSEC would be fine. If it doesn't, then the system is losing\nthe nanosecond information when it drops the cache and has to reload\nfrom disk (and thus USE_NSEC would cause spurious stat mismatches).\n\nOn my ext4 system, I get the same answers. So far so good.\n\nI get the same answers with a loopback-mounted ext2 system. Which\nsurprised me a bit, but even unmounting and remounting the filesystem,\nthe nanosecond times are still there. So...I guess ext2 supports\nnanoseconds.\n\nI tried with a vfat mount, and it also works: we don't have nanoseconds\neither before or after. That makes sense, and implies that modern Linux\nwill always be OK (because it limits the cached VFS response to what the\nunderlying filesystem can handle).\n\nSo...maybe this is just a non-issue these days, at least on Linux?\n\n> > But that's all outside the scope of your patch here.\n> \n> Kind of, I guess. If we figure that this mechanism is still subtly broken\n> then I'd argue that it doesn't make sense to expose the option via\n> Meson.\n\nTrue, but AFAICT it probably is safe these days, at least one some\nplatforms.\n\n-Peff\n"},{"id":"546595","messageId":"20260628084815.GA111587@coredump.intra.peff.net","threadId":"65848","inReplyTo":"20260628081806.GA3594700@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-28T08:48:15Z","receivedAt":"2026-06-28T08:48:17Z","isPatch":true,"body":"On Sun, Jun 28, 2026 at 04:18:07AM -0400, Jeff King wrote:\n\n> I tried with a vfat mount, and it also works: we don't have nanoseconds\n> either before or after. That makes sense, and implies that modern Linux\n> will always be OK (because it limits the cached VFS response to what the\n> underlying filesystem can handle).\n> \n> So...maybe this is just a non-issue these days, at least on Linux?\n\nOh, I also ran across this old thread:\n\n https://public-inbox.org/git/5605D88A.20104%40gmail.com/\n\nthat implies similar:\n\n * In-core file times may not be properly rounded to on-disk\n precision, causing spurious file time changes when the cache is\n refreshed from disk. This was fixed for typical Unix file systems\n in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will\n be in kernel 4.3. There's no fix for FAT-based file systems yet.\n\nI also tested with CIFS on my system and it is fine. It looks like FAT\nsystems were fixed since 2015. ;)\n\nBut there is another interesting question raised there, which is how\ndifferent implementations may interact (e.g., two versions of Git\nwithout and without USE_NSEC, or JGit which may have to use\nmillisecond-resolution APIs, etc). It should all work correctly as long\nas each implementation consistently uses its own resolution (so JGit\nwould have to compare in millisecond-space and treat ties as racy). And\nI think that is _probably_ what is happening now, since we already store\nnanoseconds unconditionally (and only use them with USE_NSEC).\n\nThough the opposite case is a performance problem but not a correctness\none: if JGit writes out an index with milliseconds and USE_NSEC Git\ntries to read it, we will consider everything stat-dirty and re-read the\ncontents.\n\nI don't know if these would be a problem in practice or not, but it's an\ninteresting potential gotcha. And one that nobody may have noticed,\nbecause probably hardly anybody bothers to build with USE_NSEC now.\n\n-Peff\n"},{"id":"546617","messageId":"akG7AJxeiWc8KUYN@fruit.crustytoothpaste.net","threadId":"65848","inReplyTo":"20260628084815.GA111587@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-06-29T00:23:28Z","receivedAt":"2026-06-29T00:30:39Z","isPatch":true,"body":"On 2026-06-28 at 08:48:15, Jeff King wrote:\n> Oh, I also ran across this old thread:\n> \n> https://public-inbox.org/git/5605D88A.20104%40gmail.com/\n> \n> that implies similar:\n> \n> * In-core file times may not be properly rounded to on-disk\n> precision, causing spurious file time changes when the cache is\n> refreshed from disk. This was fixed for typical Unix file systems\n> in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will\n> be in kernel 4.3. There's no fix for FAT-based file systems yet.\n> \n> I also tested with CIFS on my system and it is fine. It looks like FAT\n> systems were fixed since 2015. ;)\n> \n> But there is another interesting question raised there, which is how\n> different implementations may interact (e.g., two versions of Git\n> without and without USE_NSEC, or JGit which may have to use\n> millisecond-resolution APIs, etc). It should all work correctly as long\n> as each implementation consistently uses its own resolution (so JGit\n> would have to compare in millisecond-space and treat ties as racy). And\n> I think that is _probably_ what is happening now, since we already store\n> nanoseconds unconditionally (and only use them with USE_NSEC).\n> \n> Though the opposite case is a performance problem but not a correctness\n> one: if JGit writes out an index with milliseconds and USE_NSEC Git\n> tries to read it, we will consider everything stat-dirty and re-read the\n> contents.\n> \n> I don't know if these would be a problem in practice or not, but it's an\n> interesting potential gotcha. And one that nobody may have noticed,\n> because probably hardly anybody bothers to build with USE_NSEC now.\n\nI would suggest that we provide a config knob and then build with\nUSE_NSEC by default. Most people are using Linux with typical Unix file\nsystems, NTFS, CIFS, or FUSE (e.g., sshfs). In the event someone\ndetects a problem, there's an easy solution—adjust the knob—and we can\nthen add a Linux-specific statfs call to determine if the file system is\na safe one in a future version.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"546624","messageId":"akIL6oJgUv8J8SB2@pks.im","threadId":"65848","inReplyTo":"20260628081806.GA3594700@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-29T06:08:42Z","receivedAt":"2026-06-29T06:08:54Z","isPatch":true,"body":"On Sun, Jun 28, 2026 at 04:18:06AM -0400, Jeff King wrote:\n> On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:\n> \n> > > So I guess if we wanted to go further it would take some digging as to\n> > > how each platform behaves, and then flipping the config.make.uname knob\n> > > for ones where it can be argued that the behavior is always reasonable.\n> > \n> > Yeah, it would be nice indeed to figure out whether these concerns still\n> > apply. If they do, I would argue that it might even make sense to remove\n> > the build option completely. It doesn't really make sense in my opinion\n> > to have a build option that nobody uses and that is subtly broken when\n> > enabled.\n> \n> I suspect it works just fine on some platforms and some filesystems\n> (i.e., those that actually store nanoseconds on disk). So probably Linux\n> with ext4 is OK. That's just guessing, though.\n> \n> If I understand the original problem correctly, then doing this:\n> \n> touch foo\n> ls --full-time foo\n> echo 3 | sudo tee /proc/sys/vm/drop_caches\n> ls --full-time foo\n> \n> should be instructive. If it shows the same time for both \"ls\" calls,\n> then USE_NSEC would be fine. If it doesn't, then the system is losing\n> the nanosecond information when it drops the cache and has to reload\n> from disk (and thus USE_NSEC would cause spurious stat mismatches).\n> \n> On my ext4 system, I get the same answers. So far so good.\n> \n> I get the same answers with a loopback-mounted ext2 system. Which\n> surprised me a bit, but even unmounting and remounting the filesystem,\n> the nanosecond times are still there. So...I guess ext2 supports\n> nanoseconds.\n> \n> I tried with a vfat mount, and it also works: we don't have nanoseconds\n> either before or after. That makes sense, and implies that modern Linux\n> will always be OK (because it limits the cached VFS response to what the\n> underlying filesystem can handle).\n> \n> So...maybe this is just a non-issue these days, at least on Linux?\n> \n> > > But that's all outside the scope of your patch here.\n> > \n> > Kind of, I guess. If we figure that this mechanism is still subtly broken\n> > then I'd argue that it doesn't make sense to expose the option via\n> > Meson.\n> \n> True, but AFAICT it probably is safe these days, at least one some\n> platforms.\n\nHm. That makes me wonder whether it is the completely wrong approach to\nmake this a build option then. If it works on some systems and only on\nsome filesystems, then a build option is just too coarse-grained. A\ndistro wouldn't really be able to ever enable the option, unless it knew\nthat repositories will only ever exist on a filesystem that works. Which\nI guess is an assumption that no distro can make.\n\nSo instead, I wonder whether we should treat this the same as for\nexample \"core.ignoreCase\", where we only use nanosecond resolution when\nopted in by the user. Ideally, if we had a way to detect brokenness, we\ncould even make git-init(1) set it automatically.\n\nIf so, we could unconditionally enable nanoseconds on platforms that\nsupport them, but still have a runtime toggle for filesystems that\ndon't.\n\nPatrick\n"},{"id":"546718","messageId":"xmqqmrwdt4cg.fsf@gitster.g","threadId":"65848","inReplyTo":"akIL6oJgUv8J8SB2@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-29T21:38:07Z","receivedAt":"2026-06-29T21:38:10Z","isPatch":true,"body":"Patrick Steinhardt writes:\n\n> Hm. That makes me wonder whether it is the completely wrong approach to\n> make this a build option then. If it works on some systems and only on\n> some filesystems, then a build option is just too coarse-grained. A\n> distro wouldn't really be able to ever enable the option, unless it knew\n> that repositories will only ever exist on a filesystem that works. Which\n> I guess is an assumption that no distro can make.\n\nYes and no. Build options are not only for distro packagers who aim\nfor widest audience. If you know the target box with its\nfilesystems happen to be OK with the option, flipping the switch to\nturn it on is totally a sensible thing to do. It is true that this\none is much less flexible (because the situation you must be in to\nenable it is much narrower).\n\n> So instead, I wonder whether we should treat this the same as for\n> example \"core.ignoreCase\", where we only use nanosecond resolution when\n> opted in by the user. Ideally, if we had a way to detect brokenness, we\n> could even make git-init(1) set it automatically.\n\nI like the line of thought.\n\nThe ignoreCase MUST be set for correct operation if your filesystem\nis incapable of case sensitive operation, and if your filesystem is\ncase sensitive, building with ignoreCase set may limit what you can\ndo, and give you some performace hits, but also the code can make\nassumptions like \"ah, we saw 'Makefile' in this directory so there\nwouldn't be makefile at the same time\" and misbehave). In other\nwords, it is not something you set by choice.\n\nOn the other hand, nanosecond timestamp does not have to be enabled\neven if your filesystem and operating system is capable of keeping\nthe timestamp always down to nanosecond resolution, even though it\nhas to be disabled if your filesystem and operating system randomly\nloses precision due to buffer cache getting flushed. So there is a\nslight difference between it and the ignoreCase situation.\n"},{"id":"546731","messageId":"20260630054314.GD2495216@coredump.intra.peff.net","threadId":"65848","inReplyTo":"akIL6oJgUv8J8SB2@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-30T05:43:14Z","receivedAt":"2026-06-30T05:43:15Z","isPatch":true,"body":"On Mon, Jun 29, 2026 at 08:08:42AM +0200, Patrick Steinhardt wrote:\n\n> > True, but AFAICT it probably is safe these days, at least one some\n> > platforms.\n> \n> Hm. That makes me wonder whether it is the completely wrong approach to\n> make this a build option then. If it works on some systems and only on\n> some filesystems, then a build option is just too coarse-grained. A\n> distro wouldn't really be able to ever enable the option, unless it knew\n> that repositories will only ever exist on a filesystem that works. Which\n> I guess is an assumption that no distro can make.\n> \n> So instead, I wonder whether we should treat this the same as for\n> example \"core.ignoreCase\", where we only use nanosecond resolution when\n> opted in by the user. Ideally, if we had a way to detect brokenness, we\n> could even make git-init(1) set it automatically.\n\nYeah, this came up earlier in the thread. It would be nice if we could\nset it automatically, but I'm not sure we have a good way of testing a\nparticular filesystem. I think the sequence is:\n\n 1. stat() a file, getting nanoseconds\n\n 2. somehow flush the kernel's in-core inode cache\n\n 3. stat() it again and compare\n\nStep 2 is the tricky part. ;) It's not only not portable, but probably\nsomething that would annoy users if we did it for every repo creation.\n\nIt would also be nice if we could actually verify that the sequence\nabove _does_ show the problem. I was not able to come up with a failing\ninstance on my modern Linux machine (even going as far as unmounting and\nre-mounting for step 2).\n\nBut I do agree in general that it should be a config flag and not a\nbuild option. Run-time flags are more friendly to users when there is no\ngood reason to avoid them.\n\n-Peff\n"},{"id":"547104","messageId":"CALnO6CDAG4e4A_Qn-3QVe0s4D9xB333Sp0QRntNATwMygNXmQg@mail.gmail.com","threadId":"65848","inReplyTo":"ajjuoS5Qc3K0nCRl@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-07-03T15:46:14Z","receivedAt":"2026-07-03T15:46:26Z","isPatch":true,"body":"[with apologies for the delay; I wasn't paying attention to \"What's\ncooking\" to notice that this was waiting on my response.]\n\nOn Mon, Jun 22, 2026 at 4:13 AM Patrick Steinhardt wrote:\n>\n> On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:\n> > On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:\n> >\n> > > Autotools-style builds permit enabling USE_NSEC for cases where that's\n> > > desired; the equivalent knob is missing from meson-based builds.\n> >\n> > Seems reasonable. This is not changing the defaults at all, but just\n> > bringing meson's options to parity with the Makefile.\n\nFor now, I still think this makes me in favor of the patch: source\ndistributions like Gentoo can then offer the build knob for those who,\nin Junio's words\n\n> know the target box with its filesystems happen to be OK with the option\n\nOtherwise, the discussion would suggest removing it from Makefile as\nan option :)\n\n> I was originally wondering whether I should recommend that Meson can\n> auto-discover the availability of nanoseconds. But your below remarks\n> make me question that.\n>\n> > I'm not still not sure if turning on USE_NSEC is a good idea. There's\n> > some discussion in Documentation/technical/racy-git.adoc:\n> >\n> > With `USE_NSEC`\n> > compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`\n> > members are also compared. On Linux, this is not enabled by default\n> > because in-core timestamps can have finer granularity than\n> > on-disk timestamps, resulting in meaningless changes when an\n> > inode is evicted from the inode cache. See commit 8ce13b0\n> > of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git\n> > ([PATCH] Sync in core time granularity with filesystems,\n> > 2005-01-04). This patch is included in kernel 2.6.11 and newer, but\n> > only fixes the issue for file systems with exactly 1 ns or 1 s\n> > resolution. Other file systems are still broken in current Linux\n> > kernels (e.g. CEPH, CIFS, NTFS, UDF), see\n> > https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/\n> >\n> > That's the most succinct description of the problem I've seen, but I\n> > have no idea how widely it still applies. Kernel 2.6.11 is quite old\n> > now, but I could believe that other filesystems (especially network\n> > ones) still exhibit the issue.\n> >\n> > So I guess if we wanted to go further it would take some digging as to\n> > how each platform behaves, and then flipping the config.make.uname knob\n> > for ones where it can be argued that the behavior is always reasonable.\n>\n> Yeah, it would be nice indeed to figure out whether these concerns still\n> apply. If they do, I would argue that it might even make sense to remove\n> the build option completely. It doesn't really make sense in my opinion\n> to have a build option that nobody uses and that is subtly broken when\n> enabled.\n>\n> > But that's all outside the scope of your patch here.\n>\n> Kind of, I guess. If we figure that this mechanism is still subtly broken\n> then I'd argue that it doesn't make sense to expose the option via\n> Meson.\n>\n> Patrick\n\nThis bit addressed more down-thread, so I'll reply there.\n\nTo summarize: If we're all leaning in the direction of a run-time flag\ninstead, I can noodle in that direction. That certainly involves a bit\nmore surgery than just giving Meson access to the option, but the\ndynamism may be nice. I'm not too sure how we'd write a test case for\nit, though.\n"},{"id":"547105","messageId":"CALnO6CD622_PZ44rNbryKpX1Z87X92eXCuLVo4H-4nJ2JYO_kg@mail.gmail.com","threadId":"65848","inReplyTo":"20260628081806.GA3594700@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-07-03T15:46:17Z","receivedAt":"2026-07-03T15:46:29Z","isPatch":true,"body":"FWIW…\n\nOn Sun, Jun 28, 2026 at 4:18 AM Jeff King wrote:\n>\n> On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:\n>\n> > > So I guess if we wanted to go further it would take some digging as to\n> > > how each platform behaves, and then flipping the config.make.uname knob\n> > > for ones where it can be argued that the behavior is always reasonable.\n> >\n> > Yeah, it would be nice indeed to figure out whether these concerns still\n> > apply. If they do, I would argue that it might even make sense to remove\n> > the build option completely. It doesn't really make sense in my opinion\n> > to have a build option that nobody uses and that is subtly broken when\n> > enabled.\n>\n> I suspect it works just fine on some platforms and some filesystems\n> (i.e., those that actually store nanoseconds on disk). So probably Linux\n> with ext4 is OK. That's just guessing, though.\n>\n> If I understand the original problem correctly, then doing this:\n>\n> touch foo\n> ls --full-time foo\n> echo 3 | sudo tee /proc/sys/vm/drop_caches\n> ls --full-time foo\n>\n> should be instructive. If it shows the same time for both \"ls\" calls,\n> then USE_NSEC would be fine. If it doesn't, then the system is losing\n> the nanosecond information when it drops the cache and has to reload\n> from disk (and thus USE_NSEC would cause spurious stat mismatches).\n>\n> On my ext4 system, I get the same answers. So far so good.\n>\n> I get the same answers with a loopback-mounted ext2 system. Which\n> surprised me a bit, but even unmounting and remounting the filesystem,\n> the nanosecond times are still there. So...I guess ext2 supports\n> nanoseconds.\n\nI also get 9 digits of fractional precision (nanoseconds) with the\nsame answers across dropped cache on my XFS system.\n\n> I tried with a vfat mount, and it also works: we don't have nanoseconds\n> either before or after. That makes sense, and implies that modern Linux\n> will always be OK (because it limits the cached VFS response to what the\n> underlying filesystem can handle).\n>\n> So...maybe this is just a non-issue these days, at least on Linux?\n>\n> > > But that's all outside the scope of your patch here.\n> >\n> > Kind of, I guess. If we figure that this mechanism is still subtly broken\n> > then I'd argue that it doesn't make sense to expose the option via\n> > Meson.\n>\n> True, but AFAICT it probably is safe these days, at least one some\n> platforms.\n>\n> -Peff\n"},{"id":"547106","messageId":"CALnO6CDm74rCBQu6Q0djsvtuw5U14V=PApptcZTgP+pic1f_AA@mail.gmail.com","threadId":"65848","inReplyTo":"20260630054314.GD2495216@coredump.intra.peff.net","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-07-03T15:46:21Z","receivedAt":"2026-07-03T15:46:33Z","isPatch":true,"body":"On Tue, Jun 30, 2026 at 1:43 AM Jeff King wrote:\n>\n> On Mon, Jun 29, 2026 at 08:08:42AM +0200, Patrick Steinhardt wrote:\n>\n> > > True, but AFAICT it probably is safe these days, at least one some\n> > > platforms.\n> >\n> > Hm. That makes me wonder whether it is the completely wrong approach to\n> > make this a build option then. If it works on some systems and only on\n> > some filesystems, then a build option is just too coarse-grained. A\n> > distro wouldn't really be able to ever enable the option, unless it knew\n> > that repositories will only ever exist on a filesystem that works. Which\n> > I guess is an assumption that no distro can make.\n> >\n> > So instead, I wonder whether we should treat this the same as for\n> > example \"core.ignoreCase\", where we only use nanosecond resolution when\n> > opted in by the user. Ideally, if we had a way to detect brokenness, we\n> > could even make git-init(1) set it automatically.\n>\n> Yeah, this came up earlier in the thread. It would be nice if we could\n> set it automatically, but I'm not sure we have a good way of testing a\n> particular filesystem. I think the sequence is:\n>\n> 1. stat() a file, getting nanoseconds\n>\n> 2. somehow flush the kernel's in-core inode cache\n>\n> 3. stat() it again and compare\n>\n> Step 2 is the tricky part. ;) It's not only not portable, but probably\n> something that would annoy users if we did it for every repo creation.\n>\n> It would also be nice if we could actually verify that the sequence\n> above _does_ show the problem. I was not able to come up with a failing\n> instance on my modern Linux machine (even going as far as unmounting and\n> re-mounting for step 2).\n\nBrian suggested in a sibling message that a statfs call could be used\nfor \"known-good\" file system types, IIUC.\n\n> But I do agree in general that it should be a config flag and not a\n> build option. Run-time flags are more friendly to users when there is no\n> good reason to avoid them.\n>\n> -Peff\n\nIf we're all leaning in the direction of a run-time flag instead, I\ncan noodle in that direction. That certainly involves a bit more\nsurgery than just giving Meson access to the option, but the dynamism\nmay be nice. I'm not too sure how we'd write a test case for it,\nthough.\n"},{"id":"547197","messageId":"aktOn-3K41Uhl9cr@pks.im","threadId":"65848","inReplyTo":"CALnO6CDAG4e4A_Qn-3QVe0s4D9xB333Sp0QRntNATwMygNXmQg@mail.gmail.com","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-07-06T06:43:43Z","receivedAt":"2026-07-06T06:43:54Z","isPatch":true,"body":"On Fri, Jul 03, 2026 at 11:46:14AM -0400, D. Ben Knoble wrote:\n> [with apologies for the delay; I wasn't paying attention to \"What's\n> cooking\" to notice that this was waiting on my response.]\n> \n> On Mon, Jun 22, 2026 at 4:13 AM Patrick Steinhardt wrote:\n> > On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:\n> > > But that's all outside the scope of your patch here.\n> >\n> > Kind of, I guess. If we figure that this mechanism is still subtly broken\n> > then I'd argue that it doesn't make sense to expose the option via\n> > Meson.\n> \n> This bit addressed more down-thread, so I'll reply there.\n> \n> To summarize: If we're all leaning in the direction of a run-time flag\n> instead, I can noodle in that direction. That certainly involves a bit\n> more surgery than just giving Meson access to the option, but the\n> dynamism may be nice. I'm not too sure how we'd write a test case for\n> it, though.\n\nI don't think we'd necessarily need a way to detect this. Our current\nbuild default is to have this disabled, so I'd keep it this way, but\nautomatically compile nsec-support into Git if available. And then we\nprovide a way for users to opt-in to the new behaviour via the config.\n\nAn automated test would of course be nice to have so that we know to\nenable this in cases where we can determine that it works. But with the\nabove we'd already make the feature more accessible than it currently\nis, because I'd expect that most distros simply don't enable the build\ntoggle at all.\n\nPatrick\n"},{"id":"547284","messageId":"20260707043850.GC677056@coredump.intra.peff.net","threadId":"65848","inReplyTo":"aktOn-3K41Uhl9cr@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-07T04:38:50Z","receivedAt":"2026-07-07T04:38:52Z","isPatch":true,"body":"On Mon, Jul 06, 2026 at 08:43:43AM +0200, Patrick Steinhardt wrote:\n\n> > To summarize: If we're all leaning in the direction of a run-time flag\n> > instead, I can noodle in that direction. That certainly involves a bit\n> > more surgery than just giving Meson access to the option, but the\n> > dynamism may be nice. I'm not too sure how we'd write a test case for\n> > it, though.\n> \n> I don't think we'd necessarily need a way to detect this. Our current\n> build default is to have this disabled, so I'd keep it this way, but\n> automatically compile nsec-support into Git if available. And then we\n> provide a way for users to opt-in to the new behaviour via the config.\n\nYeah, agreed. Even if we eventually auto-detect, the first step is\nadding the config at all. And then we can decide whether to stop there\nor not.\n\nI'm agnostic on whether we add USE_NSEC to meson in the meantime, if it\nmight eventually be ripped out of the Makefile. We _could_ retain\nUSE_NSEC to change the unconfigured default for a given build, but I'd\nbe inclined to just remove it entirely once the runtime config is\navailable.\n\n-Peff\n"},{"id":"547868","messageId":"xmqqa4rx9mb5.fsf@gitster.g","threadId":"65848","inReplyTo":"aktOn-3K41Uhl9cr@pks.im","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-11T22:46:38Z","receivedAt":"2026-07-11T22:46:42Z","isPatch":true,"body":"Patrick Steinhardt writes:\n\n> I don't think we'd necessarily need a way to detect this. Our current\n> build default is to have this disabled, so I'd keep it this way, but\n> automatically compile nsec-support into Git if available. And then we\n> provide a way for users to opt-in to the new behaviour via the config.\n>\n> An automated test would of course be nice to have so that we know to\n> enable this in cases where we can determine that it works. But with the\n> above we'd already make the feature more accessible than it currently\n> is, because I'd expect that most distros simply don't enable the build\n> toggle at all.\n\nIn any case, the discussion tells me that if we were to pursue this\ntopic further, it would not primarily be about adding the build knob\nto meson.build file, but rather a bit more involved to affect the\nproduct for everybody regardless of the build framework used.\n\nSo I think it is safe for me discard this topic from my tree for\nnow, with an invitation to resurrect it as a topic with shifted\nfocus.\n\nThanks.\n"},{"id":"548044","messageId":"45F2C180-1DE1-4371-869B-BF605B64E01A@gmail.com","threadId":"65848","inReplyTo":"xmqqa4rx9mb5.fsf@gitster.g","subject":"Re: [PATCH] meson: wire up USE_NSEC build knob","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-07-13T22:17:39Z","receivedAt":"2026-07-13T22:17:51Z","isPatch":true,"body":"\n> Le 11 juil. 2026 à 18:46, Junio C Hamano a écrit :\n> \n> Patrick Steinhardt writes:\n> \n>> I don't think we'd necessarily need a way to detect this. Our current\n>> build default is to have this disabled, so I'd keep it this way, but\n>> automatically compile nsec-support into Git if available. And then we\n>> provide a way for users to opt-in to the new behaviour via the config.\n>> \n>> An automated test would of course be nice to have so that we know to\n>> enable this in cases where we can determine that it works. But with the\n>> above we'd already make the feature more accessible than it currently\n>> is, because I'd expect that most distros simply don't enable the build\n>> toggle at all.\n> \n> In any case, the discussion tells me that if we were to pursue this\n> topic further, it would not primarily be about adding the build knob\n> to meson.build file, but rather a bit more involved to affect the\n> product for everybody regardless of the build framework used.\n> \n> So I think it is safe for me discard this topic from my tree for\n> now, with an invitation to resurrect it as a topic with shifted\n> focus.\n> \n> Thanks.\n\nYep, I’d been meaning to send a « please discard » message per the new guidelines ;) been on vacation. "}]}