Modifying file access time upon exec...
Max Okumoto
okumoto at ucsd.edu
Tue May 31 13:54:57 PDT 2005
Bruce Evans wrote:
[lots of stuff deleted]
>
> 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 can't confirm this yet, since I have not gotten to that part of
make. But from the docs, it looks like make(1) caches the stat()
info. Which might explain why it mostly works over NFS.
make docs in the usr.bin/make/PSD.doc/tutorial.ms Section 4.1
Something you should know about the way search paths are
implemented is that each directory is read, and its contents
cached, exactly once -- when it is first encountered -- so
any changes to the directories while PMake is running will
not be noted when searching for implicit sources, nor will
they be found when PMake attempts to discover when the file
was last modified, unless the file was created in the cur-
rent directory. While people have suggested that PMake
should read the directories each time, my experience sug-
gests that the caching seldom causes problems. In addition,
not caching the directories slows things down enormously
because of PMake's attempts to apply transformation rules
through non-existent files -- the number of extra file-sys-
tem searches is truly staggering, especially if many files
without suffixes are used and the null suffix isn't changed
from .out.
Max Okumoto
[stuff deleted]
More information about the freebsd-arch
mailing list