bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Turner
Subject: Re: [Bug-tar] [patch] O_NOATIME support
Date: Tue, 20 Sep 2005 14:10:06 -0700
User-agent: KMail/1.7.1

> But this problems will merely cause us to fall back to using utimes,
> and even then the problem will occur only if this is the first file
> that we've seen in the file system, assuming that we've cached the
> noatime flag.  That's OK for a heuristic, I think.

Does that mean that you want to run the heuristic on every file in the 
filesystem, if there is indeed no O_NOATIME support? That could be a pretty 
high cost, especially if there are lots of small files.

> > Also, on some filesystems, the atime might not
> > change right away, introducing a second race condition.
>
> Is that true even for the process that is actually reading the file?
> I thought it had to do with NFS access, where one process on one host
> is reading and another process on a different host is statting.

Sure. If the file is already in the NFS cache, then there will be no read on 
the server, and therefore no atime update.

> >> > +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.
>
> I still don't get it.  Either way, the code needs to inspect a symbol;
> does it really matter whether it's "#ifdef O_NOATIME" or "#if
> HAVE_NOATIME"?

It doesn't. But then you have to wrap any reference to O_NOATIME around 
#ifdefs. As it is, the code itself doesn't have any O_NOATIME-related 
preprocessor directives at all.

Cheers,

--Ian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]