Date: Sun, 04 May 2003 16:51:02 -0700 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: Bruce Evans <bde@zeta.org.au> Cc: Jens Schweikhardt <schweikh@FreeBSD.org> Subject: Re: Access times on executables (kern/25777) Message-ID: <200305042351.h44Np2Th017215@beastie.mckusick.com> In-Reply-To: Your message of "Sun, 04 May 2003 11:42:24 %2B1000." <20030504110643.Q1248@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Sun, 4 May 2003 11:42:24 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick <mckusick@mckusick.com> cc: Jens Schweikhardt <schweikh@FreeBSD.org>, "" <arch@FreeBSD.org>, Brian Buhrow <buhrow@lothlorien.nfbcal.org> Subject: Re: Access times on executables (kern/25777) In-Reply-To: <200305040032.h440WvTh015707@beastie.mckusick.com> X-ASK-Info: Whitelist match This doesn't work unless the user has permission to change the atime using utimes(2) with a non-NULL times pointer. My version of it has a VA_EXECVE_ATIME flag which tells VOP_SETATTR() to bypass the permissions checks. I only implemented checking this flag for ufs. Another problem with setting the atime like utimes() would instead of like read() would is that utimes() is required to update the times immediately, so VOP_SETATTR() does this, but updates for read() are normally optimized to just set a flag. The difference is not large for ufs since the UFS_UPDATE() call in ufs_setattr() doesn't wait. The VA_EXECVE_ATIME flag could be used to optimize this, but I didn't try this. The overhead for setting atimes on exec only seemed to be large for nfs. This was before nfs had an attribute cache, and I think it is unavoidable for utimes()-like updates. On one of my systems now, futimes() takes about 12.5 times longer than reading 1 byte from a file on an nfs-mounted file system with the server's file system mounted -async (239 usec versus 19 usec averaged over for 10^4 futimes()s and 10^6 read()s). Bruce OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ one byte of data. It will run with the speed of read (and indeed since we just mapped in the header above, the data should be in the cache). It has the benefit of speed and not requiring the user to own the file. It has the drawback of requiring that the file be readable though most executables are set to be readable. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305042351.h44Np2Th017215>