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

[Paul Eggert]

Ian Turner <address@hidden> writes:

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

Ouch.  Good point.

> I don't see any way around this, other than second-guessing yourself
> all the time.

That's the best we can do, then.  It could be worse.

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

I'd rather avoid that if possible, since we'd rather not maintain a list
of file systems known not to work (or ones known to work, which would be
more conservative).

> 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

Yes, I think it's a maintenance hassle, and would rather avoid it.

> a sysctl could be added to ask this question to a future kernel, so
> that we would only need to use uname() for, say, kernels 2.6.8 -
> 2.6.14.

That's a better idea, but wouldn't it be better yet to make it an
fpathconf query?  It's a per-file-system issue, after all.  (While
we're on the subject, I'd also like to see an fpathconf query to give
me the resolution of the file system's time stamps in nanoseconds.)

Or -- better yet -- why not have open(...O_NOATIME) fail with errno ==
EINVAL when invoked on a file system that does not support O_NOATIME?
That would be similar to how open(...O_SYNC) is supposed to behave, so
it makes a lot of sense to do it that way.