From owner-freebsd-current Mon Apr 5 10:12:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id A371D14D08 for ; Mon, 5 Apr 1999 10:12:29 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA12232; Tue, 6 Apr 1999 03:10:31 +1000 Date: Tue, 6 Apr 1999 03:10:31 +1000 From: Bruce Evans Message-Id: <199904051710.DAA12232@godzilla.zeta.org.au> To: ian@apdata.com.au, wollman@khavrinen.lcs.mit.edu Subject: Re: Atime not set on execution ? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >The way programs are executed (by intention) does not run through the >code path which would touch the access time. The POSIX.1 >specification, IIRC, requires that the atime be updated when the >program exits -- this would be very inefficient to do in our VM >system. It requires only _marking_ for update "upon successful completion". Completion of exec doesn't seem to be specified properly, but it's clear that it is related to replacement of the process image and not to process lifetime. Since POSIX.1 doesn't and shouldn't specify virtual memory, we can consider the process image to be replaced when it is only replaced virtually. My quick and dirty implementation does a VOP_SETATTR(). This does a full update of the atime, but syncing the update to disk is delayed for ufs file systems, so setting atimes for exec is no worse than setting them for read. However, for nfs the updates are synchronous (or at least they were when I last tested this under nfsv2 a couple of years ago), so they are relatively expensive. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message