On Tue, May 02, 2000 at 10:31:19PM -0400, Jim Bauer wrote:
> bruce@staff.cs.usyd.edu.au (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)?
>
> Programs that compare atime to mtime to see if more data has
> been added to the file but not yet read. Do some of the "new mail"
> checkers use this? finger seems to.
Not "some", all. That is the standard method when
handling traditional UNIX mailbox files.
For that matter, doing cached access to mail-spool is always
wrong thing. (When talking about NFS, at least.)
I have ran systems where we did NFS mount things with all kinds of
performance caches enabled -- except when mounting /var/spool/mail/
which was mounted with all caches disabled...
Doing atime update (write) postponement infinitely would
be nice for e.g. laptops, but there some situations should
trigger inode update flushes -- classically laptop disks
are spun down quite soon, but e.g. CRON reads things once
a minute and can thus cause delayed a-time update.
However the material which cron reads is cached in memory,
and thus the only reason for disk spin-up is to write the
inode data..
For laptops thus just plain a-time inode updates should
not cause disk spin-up, but other (data) activation propably
should cause also inode update flush.
> --
> Jim Bauer, jfbauer@home.com
/Matti Aarnio <matti.aarnio@sonera.fi>
-
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:11 EST