From owner-freebsd-hackers Sat Mar 8 22:14:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA29523 for hackers-outgoing; Sat, 8 Mar 1997 22:14:12 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29513; Sat, 8 Mar 1997 22:14:04 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id XAA05439; Sat, 8 Mar 1997 23:14:00 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id XAA08940; Sat, 8 Mar 1997 23:14:07 -0700 (MST) Date: Sat, 8 Mar 1997 23:14:06 -0700 (MST) From: Marc Slemko To: "matthew c. mead" cc: isp@freebsd.org, hackers@freebsd.org Subject: Re: freebsd as a news server? In-Reply-To: <199703090439.XAA12069@goof.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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.