Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Aug 2001 08:00:00 -0700
From:      "Kevin Oberman" <oberman@es.net>
To:        Mike Meyer <mwm@mired.org>
Cc:        khui@cs.toronto.edu, questions@freebsd.org
Subject:   Re: Experiencing very slow raw write speeds on /dev/ad1 
Message-ID:  <200108131500.f7DF00R26487@ptavv.es.net>
In-Reply-To: Your message of "Sun, 12 Aug 2001 08:16:07 CDT." <15222.33175.427963.229610@guru.mired.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> From: Mike Meyer <mwm@mired.org>
> Date: Sun, 12 Aug 2001 08:16:07 -0500
> 
> Kevin Oberman <oberman@es.net> types:
> > 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.
> 
> The delay reclaiming deleted space is only a problem if your root is
> very tight on space. Personally, I make root file systems large enough
> to avoid the problem - a hundred meg is more than enough, even if you
> keep /var on it - and turn on softupdates.

If you have /var on it, it makes a bit of sense to turn on soft
updates, but the root partition tends to be so heavily read biased
that I really doubt it has significant impact. On the other hand,
running out of space during an installworld is a major pain. Not
dangerous, but a big time sink and a real annoyance trying to do much
with a system where /sbin is not all 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.
> 
> Don't bother turning on async for any file system that has softupdates
> enabled. Softupdates wouldn't add anything to async, and the write
> ordering done by soft udpates is incredibly dangerous on async
> disks. Which is the why async flag to mount is ignored if the file
> system has soft updates enabled.

This was intended for apples to apples testing, not normal use. I
should have made it clearer that soft updates should be disabled the
file system is mounted async.

> > 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.)
> 
> Originally, licensing prevented soft updates from being the default. I
> think you can now enable softupdates from sysinstall when you build
> the file systems. Setting things up to provide defaults for each file
> system would be the next step.

Yes, but, while the option is available at install time, most users
don't enable it because they don't know what it is. I want to see it
as default and I believe that I will in V5.

> The other thing you can do to improve file system performance turn on
> noatime, which will save a write whenever a file is read.

But understand that this can have an adverse impact on some software
that uses atime. This is discussed on the tuning man page on -stable
systems and coming to 4.4 real soon. Also, you are now tilting the
field unfairly as Linux does atime by default. For a fair comparison,
turn it on or off for both.

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?200108131500.f7DF00R26487>