[Bug-tar] Re: [patch] O_NOATIME support

[Ian Turner]

Paul,

It's a fine heuristic. I'm still concerned that we read a small file on NFS at 
the beginning of the archive, which happens to be in cache, and decide at 
that point that O_NOATIME works for the entire filesystem, when actually, it 
doesn't. I don't see any way around this, other than second-guessing yourself 
all the time.

Another, possibly more reliable way of detecting this, would just be to do 
statfs(), and see if the filesystem type is one known to not work. Then you 
(probably) don't have to worry about false negatives; the only way O_NOATIME 
won't work in that case is if the kernel doesn't support it, so the only bad 
behavior allowed by the heuristic is to call utimes() on possibly several 
files at the beginning of the archive, until it finds one that isn't being 
accessed, at which time it would switch to O_NOATIME.

Another approach might just be to ask the kernel (via uname()) if it supports 
O_NOATIME -- that is, if it is at least version 2.6.8. If that's too much of 
a hack, a sysctl could be addde to ask this question to a future kernel, so 
that we would only nede to use uname() for, say, kernels 2.6.8 - 2.6.14.

Cheers,

--Ian

On Wednesday 21 September 2005 16:02, you wrote:
> Ian Turner <address@hidden> writes:
> > Ah, so you're thinking of something like stat, read the whole file, and
> > stat again.
>
> No, I wasn't thinking of adding any more system calls in the usual
> case.  Tar already records the time that it starts up.
>
> Here is the heuristic I was thinking of, to be done just after we've
> finished reading the file:
>
>   * If the file is empty, stop.
>
>   * If we have already detected that O_NOATIME works for this file system,
>     stop.
>
>   * If the final fstat (which tar is already doing) reports a
>     last-access time that is older than tar's startup time, then
>     O_NOATIME worked; record this fact for the current file system,
>     and stop.
>
>   * Fall back on the existing --preserve-atime method.  I.e., use
>     futimes etc.
>
> This heuristic never uses more system calls than the existing
> --preserve-atime method.  In the usual case it never uses more system
> calls than the existing code without --preserve-atime.  It's not
> perfect, but it's better than the existing --preserve-atime in all
> cases.
>
> The heuristic can be made a bit fancier, if you like, to make the race
> condition smaller, by checking the current time and rereading a small
> part of the file before falling back on --preserve-atime.