From owner-freebsd-questions Mon Nov 26 6:20: 1 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EB9137B417 for ; Mon, 26 Nov 2001 06:19:54 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 26 Nov 2001 09:19:53 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: "Patrick O'Reilly" , "Nils Holland" Subject: Re: Softupdates Date: Mon, 26 Nov 2001 09:19:52 -0500 X-Mailer: KMail [version 1.2] Cc: "FreeBSD Question List" References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01112609195201.00903@i8k.babbleon.org> Content-Transfer-Encoding: 8bit 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 On Monday 26 November 2001 09:02, Patrick O'Reilly wrote: > > From: nils@jodie.ncptiddische.net [mailto:nils@jodie.ncptiddische.net]On > > Behalf Of Nils Holland > > Sent: 26 November 2001 15:51 > > > > On Mon, 26 Nov 2001, Patrick O'Reilly wrote: > > > I've started using softupdates on a new server. Wow!!! > > > > > > Question: Is it safe to use softupdates on ALL disks? I have a nagging > > > recollection that someone once said it should NOT be used on /. > > > > Without doubt, softupdates makes it likely that you would lose more data > > in case of a power failure or (which is very rare under FreeBSD) a system > > crash. Let's not exagerate this. The only data you are more likely to lose is the data that was in the process of being written as you crashed; if anything, soft updates will likely increase the reliability of fsck recovery (at least that's my experience; I'd had multiple fsck recovery failures without and none with); it certainly won't decrease it. Also, you most definately should turn off write-caching if you turn on softupdates. In fact, you should do this anyway: softupdates are really rather safe, but write caching is quite dangerous, and doubly so with softupdates enabled. To do this, set hw.ata.wc=0 in your /boot/loader.conf (assuming IDE devices). > > There is actually no technical reason why softupdates should not > > be enabled on /. It is only a recommendation that someone may have given, > > and it's your job to decide if you want to follow that recommendation or > > not. The main reason for this is the following, which is a very valid point, and which has a greater effect on smaller file systems and file systems that tend to be run closer to their maximum size: > > One more thing that happens in conjunction with softupdates is the > > following: If you have softupdates turned on for /usr, have a look at df > > -h before you empty /usr/obj (or any other big directory) the next time. > > Right after the directory has been emptied, do df -h again. Then wait a > > minute and do even one more df -h. You will notice that the updating of > > the free space on your filesystems gets delayed with softupdates turned > > on. This may mean that under heavy file creation activities, your > > filesystem may already be full before it's actually visible that it's > > full, And perhaps more to the point it may fill up (write failure) when it would never have filled up without softupdates. This is probably an issue for /tmp more than /, if they are on separate partitions, but at the same time /tmp is where you gain one of your biggest performance gainst, so it's better to use a large enough /tmp that you can enable softupdates on it than to disable them. If you are lucky enough to have /tmp on a separate physical drive, itdeal would be to enable write cache on /tmp as well since you don't care what you lose on /tmp if you crash . . . -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) http://www.babbleon.org -------> Free Dmitry Sklyarov! (let him go home) <----------- http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message