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

[Ian Turner]

On Monday 19 September 2005 22:36, Paul Eggert wrote:
> Thanks for bringing this to our attention.  It would be very nice to
> add this sort of thing to GNU tar.

My pleasure.

> > rather than extend the existing --preserve-atime option. The option
> > exists (as a no-op), even if configure did not find required system
> > headers.
>
> Does that sound wise?  If 'tar' can't implement --no-atime correctly,
> wouldn't it be better to reject the option?

The problem is that there is no relaible way to detect if we can actually do 
--no-atime correctly or not. Sometimes we know for sure, but I feel that if 
the option is sometimes rejected, the implication is that it will work if not 
rejected, which is not the case.

> Could you elaborate on this a bit?  It will confuse users to have both
> options.  Can't we just implement --preserve-atime with O_NOATIME if
> O_NOATIME works, and document it that way?

Except that the side-effects of --atime-preserve may make it unsuitable as a 
failover; In general, I would rather have no atime preservation than the kind 
that changes the ctime. For example, --no-atime is OK with incrementals, but 
--atime-preserve is not.

Perhaps it would be better to have --atime-preserve=system, for O_NOATIME 
only, --atime-preserve=legacy, for utimes(), or --atime-preserve=best (or 
just --atime-preserve) to guess what's best.

> Can't tar fstat the file and see whether its last access time is
> changed, after reading the file?  If it hasn't changed, O_NOATIME is
> probably working.

Nope. Consider the case where some other process is also reading the file. It 
introduces a race condition. Also, on some filesystems, the atime might not 
change right away, introducing a second race condition.

> Presumably O_NOATIME is something that works (or doesn't) on a
> per-filesystem basis.  (Am I right?)  Is there some way this can be
> queried, e.g., with stat or fpathconf?  If not, perhaps there should
> be.  And at any rate, the O_NOATIME-works info could be cached by tar
> (regardless of whether it can be queried directly).

Yes, in Linux this is a per-filesystem feature. Note, however, that the 
interface comes from the GNU folks, not the linux folks, so you may see 
O_NOATIME on other operating systems that use glibc. There's no guarantee 
from glibc that O_NOATIME will work/not work only on a particular filesystem.

No, there is no definitive way to check if a filesystem supports this. The 
best I can think of is to create a temporary file, delete it, fstat it, read 
it, and fstat it again. That assumes write permission in some directory of 
the filesystem, of course.

Probably the best guess we can do would be to statfs(), and decide if this 
filesystem is one of the ones we know is supported. But then we would have to 
keep track of kernel improvements in this area.

> > +AC_CHECK_DECL(O_NOATIME,
>
> Is the Autoconf stuff necessary?  Why not just use "#ifdef O_NOATIME"?

Mostly because it's used both in create.c and compare.c; it seemed to me 
better to have the check all in one place. Doubly so if the flag is to be 
disabled if the macro's not there.

> Also, would you be willing to assign the copyright to your changes to
> the Free Software Foundation, so that we could install it in tar?

Yes. I hereby transfer all title and ownership of this patch to the Free 
Software Foundation, under the sole condition that it be licensed at least 
under the terms of version 2 the GNU General Public License, as published by 
the Free Software Foundation.

If need be, I can get a similar transfer from my employer.

Cheers,

--Ian