Softupdates

any opinions on softupdates.

from what I gather it is what I would want to use,

then again I don't know all that much.

Would softupdates make buildworld faster?

>> Would softupdates make buildworld faster?

The opposite, maybe 20 times slower and unreliable.

freebsd:

Would you use softupdates for anything at all, for example on the /home partition, or wherever your website documents are?

In other words, is there any good side to softupdates?

>> Would you use softupdates for anything at all

Not at all because I was told by djb and many qmail gurus (like Charles Cazabon) not to use it. qmail people keep saying softupdates trades accuracy of the contents of the filesystem for speed which makes much sense to me, therefore I don't see a valid reason to enable softupdates on any partition at all.
You can do a search on google using the keyword softupdates qmail to find out more.

Speaking as someone who has used soft-updates from the begining, it not only speeds up buildworld times but ensures that recovery from power outages is more assured. It is true that since data is cached, you will lose data that is in the process of being written in the case of crash or power outage, but the file system integrety is improved and is more recoverable.
The only instances I've heard of where it is not a good idea to run softupdates, is when you have a system where the drives are close to being full or where you have questionable power or if your system is prone to crashes. Fortunantly the cost of drive space has all but eliminated the first and a good ups will take care of the second and the Freebsd OS is one of the most stable out there for the third.
I have also heard of people running softupdates on everything just because of the speed increase. For safety if you are going to use softupdates then you should turn off write cacheing on the drives.
Have a look for yourself at google groups, just do a search for softupdates and you'll see what I mean.
http://groups.google.com/groups?hl=...mailing.freebsd

>> it not only speeds up buildworld times but ensures that recovery from power outages is more assured

Not on speed though because of the implementation requires expensive resources for creating meta data files, which is why it's actually slower. That's why you'd lose speed but getting accuracy of file system in return, ONLY on power outage, and that's what UPS is for.

From the recent FreeBSD mailing lists, they are having a
discussion on this very topic right now.

As rsowders said, they also recommend turning off write caching, if you are using Softupdates, especially if you are using ATA drives.

rsowders,

When you say to turn off write caching on the drives, do you
mean that it should be turned off hardware wise, or through
FreeBSD? I have also read alot that write caching should be
disabled for saftey measure. I found the following for turning it off through FreeBSD, but no mention of turning it off on through the
card's BIOS settings:

In /boot/loader.conf, add the line:

hw.ata.wc=0

If the sysctl knob works for you that's great. Almost all IDE manufacturers provide tools to access the bios on their hard drives. It's usually a dos tool of some sort. Just boot a dos floppy and then use their tools to set the write cacheing to off. Then you'll know it's off for sure. Sometimes there are jumpers that can be set on the hard drive to disable write cacheing too.

It would be wise to visit the web sites of your hard drive manufacturer and read every thing you can about your hard drives. The major brands have a wealth of info and tools available for free to those what want use it.

BTW, this whole issue of safety of data in case of a crashed system, for me is almost moot. I usually don't care what type of drive settings I have, and I always use soft updates on everything. I've never lost data, ever. My systems just don't crash. Freebsd just doesn't crash unless your doing something extravagant and leading edge. Watch the stable mailing list and update only when issues of stability are few or far betweem. Certainly don't update during a flurry of ATA driver developement, just watch for a quiet period and test before you move it into production. Over the past 6 years I've never had a problem with this method. YMMV.

So for the home user, or hobbiest, I would say, get a decent UPS, run upsd, turn on soft updates and don't worry about it. People with critical data on production systems should not be using IDE hardware to start with, SCSI is the only way to go there IMHO.

duh what is ups?

So anyway as stated softupdate is not recommended
with qmail.

Maybe djbdns as well, I don't know yet.

But I see from 4.5 release softupdates are put on by default.

Again these things are beyond my comprehension right now but good to try and understand.

Sorry,

ups is an UPS or an Uninterruptible Power Supply.

If you purchase a smart UPS from APC you can use the upsd which is in the ports. It will talk to the smart UPS and when it gets a notification of power problems it will shut down the server gracefully and then put the UPS in standby. The UPS will sit in standby for up to a month and periodically check incoming power. When incoming power is restored it will start up the UPS and then bring up your server. All in all it's a pretty nice solution, especially when your colo is having power problems.

UPSD can be configured for how long it will stay on battery power before it brings the server down and it will even send wall messages to every logged in user every minute, warning of impending shutdown, and will also email a notification to anyone you choose.

Using the above daemon and hardware, power problems are taken out of the softupdates picture all together.

Sorry,

ups is an UPS or an Uninterruptible Power Supply.

If you purchase a smart UPS from APC you can use the upsd which is in the ports. It will talk to the smart UPS and when it gets a notification of power problems it will shut down the server gracefully and then put the UPS in standby. The UPS will sit in standby for up to a month and periodically check incoming power. When incoming power is restored it will start up the UPS and then bring up your server. All in all it's a pretty nice solution, especially when your colo is having power problems.

UPSD can be configured for how long it will stay on battery power before it brings the server down and it will even send wall messages to every logged in user every minute, warning of impending shutdown, and will also email a notification to anyone you choose.

Using the above daemon and hardware, power problems are taken out of the softupdates picture all together.

I don't know why the qmail and djbdns camps are crying about softupdates, I'm sure they have their reasons though. It's just kind of funny that they also don't tell everyone to turn off write cacheing on their IDE disks. Most of them come with write cacheing on by default, and softupdates is just a more efficient form of write cacheing.
Since I dont' use those products I can't say one way or the other, but sendmail and bind have no problem with it, and the authors of those have always been active contributors to the freebsd core group. So it looks like that for the majority of users who don't run a big email server or their own primary name server there really is no reason to use qmail or djbdns and no reason to promote either one to the masses.

I don't really want to start of flame fest here, these are just my opinions nothing more.

rsowders,

It looks like our RAID card BIOS has write caching turned off by default. That is good news.

This Oracle article recommends not using caching for OLTP. Granted, it is 2 years old, but it's the best article on RAID, striping, and caching that I have come across so far.

http://www.oracle.com/oramag/oracle...l?o30avail.html

I believe Oracle's reasoning for not using write cache, is that they believe their own system memory buffers will do a better job of caching the data. Oracle write caching is also very safe, in case of power outages, data will automatically restored to its state up to the point of failure.

For anyone else following the thread, many RAID cards have two modes for their cache, "write-thru" and "write-cache."

"Write-thru" means that, the card will not tell the OS that it has written data until it has physically written it to the disk.

"Write-cache" means that the card will "lie" to the OS, and tell it it has written changes to disk, when in reality, it has only written the changes to its memory cache. It will write data to the actual disk when it find the appropriate lull in activity.

Lots of cards have implemented a write cache because some particular RAIDs, particularly RAID5, have poor performance on writes, and therfore it's normally alot faster to write to memory than to disk. So the cache makes up for this write penalty.

The danger the gentlemen above refer to is power outages. Say your users have committed 50 records of data. You have write cache enabled, and those 50 records are stored in memory, because they have not been written to disk YET. Suddenly, your power goes out! If you don't have a backup power source to take over, you will LOSE those records, since they haven't physically been written to disk!

Most RAID vendors recommend battery backups (UPS) to safeguard against power outages. Though I have personally seen some UPS fail to kick in during power outages. Not only that, some UPS won't last very long. If you have an extended outage, you had better have a backup generator ready.

If you use UPS, make sure you stay on top of it, and check your batteries regularly. A battery change at least every 6 months is recommended.

Like rsowders, these are also my opinions. I tend to be more paranoid than most.

As some of you may know, this thread got very offtopic and decended into a flamewar. I moved the offending posts to:

http://forums.devshed.com/showthrea...&threadid=33346

If anyone is interested in the mudslinging.

Remember to be nice, boys and girls - everyone is entitled to his or her own opinion and personal insults are not nice. Please respect your fellow DevShed community members.

Carry on....

It's still offtopic in BSD forum so please move it to DNS forum.

Anyway thank you for taking the non-softupdates-related posts out of this thread to a new one, and with a descriptive subject title