Re: atime

From: Peter Moulder (reiter@netspace.net.au)
Date: Tue May 02 2000 - 04:51:30 EST


On Tue, 2 May 2000, Bruce Janson wrote:

> Maintenance of the traditional unix atime field turns read-like
> operations into write-like operations. For sophisticated network
> file systems that maintain a coherent distributed view, this
> hurts performance.
>
> Which popular/essential/useful user-level Linux applications
> break when atime is disabled (say, pegged to zero)?

Things I've used atime for:

 - Finding file creation time of a file that is still being written to but
   never been read from.

 - Finding programs/packages that I never / rarely use. (I think Debian's
   popularity-contest package uses atime to estimate the frequency of
   usage of different packages.)

Rather than pegging to zero, _I_ would prefer that atime was weakly
updated (i.e. some "logical updates" are allowed to get lost). More
specifically, we update the in-memory atime just as we do currently, but
either:

 1) not marking the inode dirty if only the atime is changed; or possibly
 2) marking it "mildly dirty", meaning that it should be written back to
    disk only if cheap to do so (e.g. if there's no other I/O to be
    done and the disk isn't spun down; on some systems this may be almost
    never). Of course the inode can also be written to disk if it is made
    dirty in some other way (e.g. ctime change).

There is one disadvantage of always updating the in-memory atime but not
always writing that change to disk: it can result in atime going backward
in time if the inode is flushed from memory without writing the updated
atime to disk. I.e.

   Read inode into memory: atime is 42.
   Read from file, update atime to 69.
   stat shows atime is 69.
   Short on memory, so discard that inode from memory since it is clean
   apart from a dirty atime field.
   stat called again: read inode into memory from disk, atime back at 42.

Nevertheless, I'd be content with this model (so long as it was a mount
etc. option just as noatime is at the moment).

pjm.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST