From owner-freebsd-questions Mon Aug 13 8: 0:29 2001 Delivered-To: freebsd-questions@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 3B75637B406 for ; Mon, 13 Aug 2001 08:00:20 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f7DF00R26487; Mon, 13 Aug 2001 08:00:00 -0700 (PDT) Message-Id: <200108131500.f7DF00R26487@ptavv.es.net> To: Mike Meyer Cc: khui@cs.toronto.edu, questions@freebsd.org Subject: Re: Experiencing very slow raw write speeds on /dev/ad1 In-reply-to: Your message of "Sun, 12 Aug 2001 08:16:07 CDT." <15222.33175.427963.229610@guru.mired.org> Date: Mon, 13 Aug 2001 08:00:00 -0700 From: "Kevin Oberman" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Mike Meyer > Date: Sun, 12 Aug 2001 08:16:07 -0500 > > Kevin Oberman 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