Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 May 2005 14:51:43 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Ken Smith <kensmith@cse.Buffalo.EDU>
Cc:        Marc Olzheim <marcolz@stack.nl>, Sergey Babkin <babkin@verizon.net>, freebsd-arch@FreeBSD.org
Subject:   Re: Re: Modifying file access time upon exec...
Message-ID:  <20050528141302.J81578@delplex.bde.org>
In-Reply-To: <1117211600.666.5.camel@opus.cse.buffalo.edu>
References:  <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 27 May 2005, Ken Smith wrote:

> On Fri, 2005-05-27 at 11:12 -0500, Sergey Babkin wrote:
>>> No, I'm saying that there are filesystems you wouldn't want to mount
>>> with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some
>>> software depends on the atime being adjusted.
>>>
>>> But atime over NFS is something you'd usually want to turn off, because
>>> it can really hurt performance.

Except it cannot really be turned off.  It can be turned off on the
server but that setting is wrong if some clients really want it on.
It cannot be turned off on clients (the mount flag for it has no effect).
FreeBSD only has broken clients which mostly don't set it as necessary,
so it is normally sort of mostly off by default.  If the clients weren't
broken then there would be a lot of nfs traffic to sync it.  See another
reply for more details.

>> As a compromise, would it make sense to make the
>> atime granularity adjustable? I.e. instead of the
>> default microsecond granularity use a 1-second
>> granularity. Or a 10-second granularity, so that the
>> atime would be adjusted only once per every 10
>> seconds. And similarly for mtime, though here
>> you should obviously be more careful.

The default granularity for ffs is already much larger than 1 second.
The precision is 1 second, but atimes are normally not changed even
in memory (they are only marked for update) until many seconds after
the even that marked them, when one of the following events occurs:
- someone looks at the times using stat(2) or friends
- the file is (last-?) closed
- the file is synced
Even with this, actual updates of atimes can be ridiculously expensive
in some (not so usual) case.  You can have a few million files cached in
few GB of memory.  No disk accesses need occur to read() or exec() these
files.  But then if somone looks at all the files using something like a
recursive grep, you have to do millions of writes to sync 8-16 bytes of
atime info for each file.  8-16 * millions of bytes might not take long
to write, but they do if they are done sparsely in millions of separate
writes.  I think the right way to implement atimes is to use a contiguous
are of disk for them and never sync them until unmount() or memory for
them runs out.

OTOH, exec()ing millions of different files in a short time seems
unlikely.  For exec(), the case to worry about is exec()ing the same file
repeatedly.  The mark-for-update method works well for this in local
file systems.  Unfortunately, simple implementations of it cannot
work for remote file systems.  Someone might stat() the file on another
client...

The 10-second granularity might be useful here.  stat() on the other
client would still need to sync with local caches/marks for update on
other clients, but the other clients and the server can know that there
is no need to sync if less than 10 seconds has elapsed since the
last tick of the 1/10 Hz clock that gives the time to possibly update
(this clock must be synchronized).

This wouldn't work for mtimes.  The granularity must be much less than
10 seconds for make(1) to work.  I'm surprised it mostly works with a
granularity of 1 second.

> I'm still a tiny bit confused but that's probably just me.  Normally
> when setting up an environment with diskless clients in it I set things
> up so that the portions of the server containing executable files are
> mounted read-only on all the clients.  I typically can't trust the
> client machines enough to grant them write access to something
> like /usr.  So, in that sort of an environment this is a non-issue.  As

Yes, this should prevent the client wasting the server's and its own time.

> mentioned above there are portions of the environment you can't do that
> for but none of those directories mentioned above would contain
> executable files.  And the places that do contain executable files
> (e.g. /usr) are mounted read-only.  So there should be no noticable
> impact from the proposed patch if that sort of setup is normal.

I use non-diskless clients with /usr nfs-mounted, not readonly and
sometimes written to, so the client should be asking for atime updates
(since it doesn't understand -noatime), but I use -noatime on all local
file systems so atimes are effectively off since -noatime works on the
server.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050528141302.J81578>