Access times on executables (kern/25777)
Kirk McKusick
mckusick at beastie.mckusick.com
Sun May 4 16:51:05 PDT 2003
Date: Sun, 4 May 2003 11:42:24 +1000 (EST)
From: Bruce Evans <bde at zeta.org.au>
X-X-Sender: bde at gamplex.bde.org
To: Kirk McKusick <mckusick at mckusick.com>
cc: Jens Schweikhardt <schweikh at FreeBSD.org>, "" <arch at FreeBSD.org>,
Brian Buhrow <buhrow at lothlorien.nfbcal.org>
Subject: Re: Access times on executables (kern/25777)
In-Reply-To: <200305040032.h440WvTh015707 at 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
More information about the freebsd-arch
mailing list