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