Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Mar 1997 01:16:11 -0500 (EST)
From:      "matthew c. mead" <mmead@goof.com>
To:        marcs@znep.com (Marc Slemko)
Cc:        isp@freebsd.org, hackers@freebsd.org
Subject:   Re: freebsd as a news server?
Message-ID:  <199703090616.BAA12521@goof.com>
In-Reply-To: <Pine.BSF.3.95.970308230319.6158P-100000@alive.znep.com> from "Marc Slemko" at Mar 8, 97 11:14:06 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Marc Slemko writes:
> 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.

	Hmm.  The above seems to suggest that the practice of
mounting async when doing a make work wouldn't help, but I recall
it making a pretty measurable difference.  What I meant in the
question I asked was, considering that I'm running 2.1.6,
mounting async probably doesn't make any difference.  Is that the
case?  Or am I just not testing things that would make any
difference?  Thanks for the reply!




-matt

-- 
Matthew C. Mead

mmead@goof.com
http://www.goof.com/~mmead/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703090616.BAA12521>