Date:        Tue, 15 Feb 2000 18:55:03 -0500 (EST)
    From:        der Mouse  <mouse@Rodents.Montreal.QC.CA>
    Message-ID:  <200002152355.SAA09516@Twig.Rodents.Montreal.QC.CA>

  | Isn't that tiny fraction enough?  Why burn cpu cycles you don't have
  | to?  Is fourteen bytes in /etc/fstab too high a price to pay for
  | shaving a hair of time off /tmp operations?  Then most certainly,
  | remove them.

It isn't the 14 bytes - it is the functionality.  I expect NetBSD systems
to remain up and running for months (at least) - in that time a lot of
trash can build up in /tmp, having the access time available is useful
for working out what is still being used, and what is just garbage that
someone didn't bother to clean up.

Since no disc accesses are (generally) involved in updating the
access time, the cost of keeping it seems very low, so I would not
suggest to anyone that they ought use the flag (or at least, not without
being very clear what the effect is).

  | They aren't going to be "all that useful", no.  But why not?  If they
  | save even one instruction per access, why on earth *not* use them?  (I
  | can see valid arguments against noatime.  But async?  It's not as if an
  | mfs will *ever* have to deal with repair after a crash, and that's what
  | async is risking.)

No, but as we have been told, async is there anyway for mfs filesystems,
whether you specify it in fstab or not.   Given that, it seems much safer
to leave it out, and avoid the risk that someone will blindly copy the
line when they are puting some other filesystem in fstab.

kre