Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2008 18:12:25 -0400
From:      Christopher Sean Hilton <chris@vindaloo.com>
To:        Daniel Bye <freebsd-questions@slightlystrange.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Does softupdate help squid ?
Message-ID:  <64A3D312-9171-4689-9786-7BE0060B1406@vindaloo.com>
In-Reply-To: <20080317201442.GA26672@torus.slightlystrange.org>
References:  <47DE312E.2030209@esiee.fr> <20080317201730.G88797@wojtek.tensor.gdynia.pl> <200803171934.06136.lists-fbsd@shadypond.com> <20080317201442.GA26672@torus.slightlystrange.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mar 17, 2008, at 4:14 PM, Daniel Bye wrote:

> On Mon, Mar 17, 2008 at 07:34:04PM +0000, Pollywog wrote:
>> On Monday 17 March 2008 19:17:58 Wojciech Puchar wrote:
>>>> i would say it's absolutely needed.
>>>
>>> anyway - any reason to not use soft updates on every filesystem?
>>
>> What exactly is a soft update?
>
> It's a bit like a hard update, but it won't hurt your disks as much
> if your system crashes... ;-P
>
> On a more serious note, it's a technique for ensuring the integrity of
> disks after a system crash or power failure.  Like journalling, they
> don't guarantee data won't be lost, but instead that the disks will be
> in a consistent state at recovery.
>

Soft updates is a means of re-ordering the writes to a filesystem such  
that the complete filesystem, both data and meta data, remains  
reasonably consistent during the writing process. This consistency is  
necessary insurance in case of a system crash or power failure during  
the writing process. Soft updates seeks to re-order the writes in such  
a way that the filesystem can be safely recovered by an automatic fsck  
process when the system is restarted. At the same time soft updates  
works to maintain high system performance . Previous to soft updates  
you could either mount the filesystem synchronously or asynchronously.  
With Synchronous mounts the filesystem meta data writes were handled  
before data writes. This caused excessive and expensive seeking from  
the disk mechanism as it moved from one part of the disk to update the  
meta-data to the other part of the disk to write the application data.  
With an asynchronous mount the kernel was free to perform the writes  
in the order most beneficial for performance but if the system crashed  
in the middle of a write one could expect a very difficult situation  
for fsck to fix.

My squid is on OpenBSD. My cache partition is spread across two  
spindles of a drive provided by the ccd driver mounted either  
asynchronously or with soft updates. Either way is fine because if my  
squid machine were to crash so hard that the cache partition was toast  
it wouldn't take but 10 minutes rebuild the filesystem from scratch  
and use squid -z to reinitialize it. For me there's really no data on  
there worthy of softupdates.

-- Chris




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64A3D312-9171-4689-9786-7BE0060B1406>