From: "Kevin Hui - DCS" <khui@cs.toronto.edu> To: "Kevin Oberman" <oberman@es.net> Cc: "Alfred Perlstein" <bright@mu.org>, <freebsd-questions@FreeBSD.ORG> Subject: Re: Experiencing very slow raw write speeds on /dev/ad1 Message-ID: <003401c123a4$63e5d560$07010101@mtwx1.on.home.com> References: <200108112350.f7BNoAR01871@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Correct me if I'm wrong, but I do not think that turning (1) and (2) on would matter in this case since they are both for file-system-level performance tuning. I am access the raw device here, bypassing the file-system layer. Thanks, -Kevin. ----- Original Message ----- From: "Kevin Oberman" <oberman@es.net> To: "Kevin Hui" <khui@cs.toronto.edu> Cc: "Alfred Perlstein" <bright@mu.org>; <freebsd-questions@FreeBSD.ORG> Sent: Saturday, August 11, 2001 7:50 PM Subject: Re: Experiencing very slow raw write speeds on /dev/ad1 > > 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?003401c123a4$63e5d560$07010101>