Date: Mon, 26 Nov 2001 09:19:52 -0500 From: Brian T.Schellenberger <bts@babbleon.org> To: "Patrick O'Reilly" <patrick@mip.co.za>, "Nils Holland" <nils@tisys.org> Cc: "FreeBSD Question List" <freebsd-questions@FreeBSD.ORG> Subject: Re: Softupdates Message-ID: <01112609195201.00903@i8k.babbleon.org> In-Reply-To: <NDBBIMKICMDGDMNOOCAIOENHDPAA.patrick@mip.co.za> References: <NDBBIMKICMDGDMNOOCAIOENHDPAA.patrick@mip.co.za>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01112609195201.00903>