Jeff King [off-list ref] writes:
quoted
+ /* Try again w/o O_CLOEXEC: the kernel might not support it */
+ if ((sha1_file_open_flag & O_CLOEXEC) && errno == EINVAL) {
+ sha1_file_open_flag &= ~O_CLOEXEC;
continue;
}
So if we start with O_CLOEXEC|O_NOATIME, we drop CLOEXEC here and try
again with just O_NOATIME. And then if _that_ fails...
quoted
+ /* Might the failure be due to O_NOATIME? */
+ if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
+ sha1_file_open_flag &= ~O_NOATIME;
+ continue;
+ }
We drop O_NOATIME, and end up with an empty flag field.
But we will never have tried just O_CLOEXEC, which might have worked.
Yes, doing so would smudge atime, so one question is which one
between noatime or cloexec is more important to be done at open(2)
time.
It may be possible to open(2) only with cloexec and then fcntl(2)
FD_SET noatime immediately after, but going that way would explode
the combination even more, as it may not be possible to set these
two flags the other way around.
I'm not sure it's worth worrying about or not; I don't know which
systems are actually lacking either of the flags, or if they tend to
have both.
On Wed, Oct 26, 2016 at 09:23:21AM -0700, Junio C Hamano wrote:
quoted
quoted
+ /* Might the failure be due to O_NOATIME? */
+ if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
+ sha1_file_open_flag &= ~O_NOATIME;
+ continue;
+ }
We drop O_NOATIME, and end up with an empty flag field.
But we will never have tried just O_CLOEXEC, which might have worked.
Yes, doing so would smudge atime, so one question is which one
between noatime or cloexec is more important to be done at open(2)
time.
Yes, but the missing case is one where we know that O_NOATIME does not
work (but O_CLOEXEC does), so we know we have to smudge the atime.
Of the two flags, I would say CLOEXEC is the more important one to
respect because it may actually impact correctness (e.g., leaking
descriptors to sub-processes). Whereas O_NOATIME is purely a performance
optimization.
I actually wonder if it is worth carrying around the O_NOATIME hack at
all. Linus added it on 2005-04-23 via 144bde78e9; the aim was to reduce
the cost of opening loose object files. Some things have changed since
then:
1. In June 2005, git learned about packfiles, which means we would do
a lot fewer atime updates (rather than one per object access, we'd
generally get one per packfile).
2. In late 2006, Linux learned about "relatime", which is generally
the default on modern installs. So performance around atime updates
is a non-issue there these days.
All the world isn't Linux, of course, but I can't help that feel
that atime performance hackery is something that belongs at the
system level, not in individual applications.
So I don't have hard numbers, but I'd be surprised if O_NOATIME is
really buying us anything these days.
-Peff