>> /dev/wd0b /tmp  mfs     rw,async,noatime,nosuid,-s=20000

> Does async on an mfs really achieve anything useful?

> I'd guess that noatime might save just a tiny fraction of cpu time,
> but is that really worth it either?

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.

But to me the question is more like "why *not* use async and noatime?".
(Indeed, that's a valid question for any mount point, but for most the
answers are trivially obvious.)

> Both of those options are really tailored to saving disc accesses
> aren't they,

Yes, at the price of risking filesystem damage in a crash (async) and
not maintaining last-read times (noatime)...neither of which is likely
to be an issue for mfs.

> and aren't really likely to be all that useful for a mfs filesys.

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.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B