Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Mar 1997 23:14:06 -0700 (MST)
From:      Marc Slemko <marcs@znep.com>
To:        "matthew c. mead" <mmead@goof.com>
Cc:        isp@freebsd.org, hackers@freebsd.org
Subject:   Re: freebsd as a news server?
Message-ID:  <Pine.BSF.3.95.970308230319.6158P-100000@alive.znep.com>
In-Reply-To: <199703090439.XAA12069@goof.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Mar 1997, matthew c. mead wrote:

> Michael Smith writes:
> > matthew c. mead stands accused of saying:
> > > > 
> > > > I really do suggest using  -o noatime,async
> > > > on mounted news partitions too (for 2.2)
> > > 
> > > 	This system is a 2.1.6 installation.  Do these
> > > recommendations change based on that?  Thanks for the replies!
> 
> > No async support in 2.1.6, but I believe that noatime is supported.
> 
> 	Hmm.  No wonder I don't see any improvement in 2.1.6
> mounting async and building the kernel.

Try creating 5000 files, mounting async, then removing them.  Try the same
thing mounted sync.  If you are close to the box and the drives aren't too
quiet, you will be able to hear the difference in addition to just seeing
a speed improvement.  You should only notice a trivial difference mounting
async for making the kernel; what mounting async does is change the fs so
metadata updates are done with bdwrite instead of bwrite.  bwrite blocks
until the data is actually written to disk while bdwrite just marks the
buffer dirty and allows it to be delayed for a while before it is actually
written.  When lots of files are being updated, allowing that buffering
speeds things up a good bit.  Making a kernel is generally cpu limited so
mounting async doesn't help much; it wouldn't make any difference for raw
throughput to a single file either. 

The reason why mounting async can be dangerous is that it can leave the
metadata (ie. inode info) in an inconsistent state; I've never lost a fs
from it, just a few files that were being written around the time a system
crashed, but fsck often fails to automatically fix it.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970308230319.6158P-100000>