Xref: utzoo comp.unix.wizards:8105 comp.os.misc:413 comp.os.vms:5837
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mtunx!whuts!homxb!hropus!jgy
From: jgy@hropus.UUCP (John Young)
Newsgroups: comp.unix.wizards,comp.os.misc,comp.os.vms
Subject: Re: Uses for access time
Message-ID: <122@hropus.UUCP>
Date: 28 Apr 88 01:09:11 GMT
References: <3672@lynx.UUCP> <609@vsi.UUCP>
Distribution: na
Organization: Bell Labs, Holmdel, NJ
Lines: 31
Posted: Wed Apr 27 21:09:11 1988

> In article <3672@lynx.UUCP>, m5@lynx.UUCP (Mike McNally ) writes:
> > I am trying to convince some of my ``colleagues'' here that keeping track
> > of last-access times of files is a useful pursuit for an operating system.
> > [...]
> > Are these reasons enough to justify the overhead (I think so)?  Are there
> > other reasons that I am overlooking?
> 
> Starting on a related topic:
> 
> I believe the access time of a UNIX file must be updated after
> each read (not just at the open).  Since mounting a filesystem
> readonly turns this update mechanism off because the inode is not
> writable, I would assume that this would speed up a filesystem
> slightly: does anybody have any experience on this?
> 
> -- 
> Steve Friedl           V-Systems, Inc.        Spaf for president!
> friedl@vsi.com   {backbones}!vsi.com!friedl    attmail!vsi!friedl

The time spent doing this is minimal.  The inode is in-core and being
accessed anyway.  The "overhead" is simply the assignment:

	iptr->a_time = lbolt;		(or whatever the clock/time is)

This is done regardless of whether or not the fs is mounted readonly.
(not worth the effort to check I suppose).  There is no need to ever
write the inode to disk until the "access" is finished with (final close)
so that't the only time when you'll get that modest saving.


			John Young