From owner-freebsd-arch@FreeBSD.ORG Tue May 31 20:54:57 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EBD416A41C for ; Tue, 31 May 2005 20:54:57 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from mailbox8.ucsd.edu (mailbox8.ucsd.edu [132.239.1.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB16443D1F for ; Tue, 31 May 2005 20:54:56 +0000 (GMT) (envelope-from okumoto@ucsd.edu) Received: from smtp.ucsd.edu (smtp-a.ucsd.edu [132.239.1.49]) by mailbox8.ucsd.edu (8.13.3/8.13.3) with ESMTP id j4VKspJC038182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 May 2005 13:54:52 -0700 (PDT) Received: from ucsd.edu (adsl-63-199-247-93.dsl.sndg02.pacbell.net [63.199.247.93]) by smtp.ucsd.edu (8.12.10/8.9.3) with ESMTP id j4VKspTg006349 for ; Tue, 31 May 2005 13:54:51 -0700 (PDT) Message-ID: <429CCF1B.1060702@ucsd.edu> Date: Tue, 31 May 2005 13:54:51 -0700 From: Max Okumoto User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <15835986.1117210354543.JavaMail.root@vms069.mailsrvcs.net> <1117211600.666.5.camel@opus.cse.buffalo.edu> <20050528141302.J81578@delplex.bde.org> In-Reply-To: <20050528141302.J81578@delplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylisting: NO DELAY (Trusted relay host); processed by UCSD_GL-v1.2 on mailbox8.ucsd.edu; Tue, 31 May 2005 13:54:52 -0700 (PDT) X-MailScanner: PASSED (v1.2.8 22921 j4VKspJC038182 mailbox8.ucsd.edu) Subject: Re: Modifying file access time upon exec... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 20:54:57 -0000 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]