Date: Sat, 11 Aug 2001 16:50:10 -0700 From: "Kevin Oberman" <oberman@es.net> To: Kevin Hui <khui@cs.toronto.edu> Cc: Alfred Perlstein <bright@mu.org>, freebsd-questions@FreeBSD.ORG Subject: Re: Experiencing very slow raw write speeds on /dev/ad1 Message-ID: <200108112350.f7BNoAR01871@ptavv.es.net> In-Reply-To: Your message of "Fri, 10 Aug 2001 11:17:55 EDT." <Pine.GSO.4.21.0108101106250.9706-100000@gardiner.cs>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 10 Aug 2001 11:17:55 -0400 > From: Kevin Hui <khui@cs.toronto.edu> > Sender: owner-freebsd-questions@FreeBSD.ORG > > > > Adding write caching helped a lot. Now the write speed jumps to ~15.8MB/s > > > instead of the previous 3.5MB/s. > > > Are there any other such settings I should pay attention to? I asked > > > because I believe that the performance is still not as good as can be. I > > > have the rawio program running under Linux with the identical hardware > > > (accessing the /dev/raw/raw0, which maps to /dev/hdb) and I got ~38.4MB/s > > > raw write speed (BTW I get ~38.4MB/s from both Linux and FreeBSD when I do > > > the single-process raw sequential read test). > > > > I'm a bit confused, where do the numbers differ and what are the numbers? > > The numbers from simple runs (standard chunk size, single I/O thread, > sequential read and then sequential write) are provided below. The > FreeBSD write number is less than half of what Linux is getting. OK. There are several things FreeBSD does that hut disk I/O performance. All are done for reliability. Linux seems to mostly worry about performance and not reliability. 1. For all but he root partition, turn on softupdate. This is done with tunefs -n enable 'filesystem'. To do this, re-boot to single user mode and use the tunefs command on each file system where you want it. It is non-volatile, so it only should be done once for each file system. You probably don't want to do this for root. It's normally not going to help much and the delay in reclaiming deleted space can cause problems there. 2. Mount the file systems as async. This is what Linux does. If there is a failure, you might lose an entire file system or an entire disk because of meta data inconsistency. Either a power failure or a crash can be devastating, although it usually won't be. I can't ever recommend running async in production, but for testing against Linux, it's the only fair comparison. I do recommend soft updates. They are safe and can substantially improve performance. I'm still not sure why soft updates are not default, but they may become default in the future, especially if background fsck works. (Background fsck can only work with soft update since a soft update system can safely run without an fsck.) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108112350.f7BNoAR01871>