[PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
torvalds at linux-foundation.org
Fri Sep 29 00:18:42 UTC 2023
On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o <tytso at mit.edu> wrote:
> I don't think anyone will complain about breaking the userspace API
> --- especially since if, say, the CIA was using this for their spies'
> drop boxes, they probably wouldn't want to admit it. :-)
Well, you will find that real apps do kind of of care.
Just to take a very real example, "git" will very much notice time
granularity issues and care - because git will cache the 'stat' times
in the index.
So if you get a different stat time (because the vfs layer has changed
some granularity), git will then have to check the files carefully
again and update the index.
You can simulate this "re-check all files" with something like this:
$ time git diff
$ rm .git/index && git read-tree HEAD
$ time git diff
so the difference between just doing a "look, index information
matches current 'stat' information" and "oops, index does not have the
stat data" is "40 milliseconds" vs "10 seconds".
That's a big difference, and you'd see that each time the granularity
changes. But then once the index file has been updated, it's back to
the good case.
So yes, real programs to cache stat information, and it matters for performance.
But I don't think any actual reasonable program will have
*correctness* issues, though - because there are certainly filesystems
out there that don't do nanosecond resolution (and other operations
like copying trees around will obviously also change times).
Anybody doing steganography in the timestamps is already not going to
have a great time, really.
More information about the samba-technical