From owner-freebsd-stable@FreeBSD.ORG Sat Apr 12 12:48:59 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30BCA37B401 for ; Sat, 12 Apr 2003 12:48:59 -0700 (PDT) Received: from PIKES.panasas.com (gw2.panasas.com [65.194.124.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id E977E43F3F for ; Sat, 12 Apr 2003 12:48:57 -0700 (PDT) (envelope-from cbehanna@panasas.com) Received: from waumbek.panasas.com ([172.17.2.36]) by PIKES.panasas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2AZK6SVN; Sat, 12 Apr 2003 15:48:57 -0400 From: Chris BeHanna Organization: Panasas, LLC To: stable@freebsd.org Date: Sat, 12 Apr 2003 15:48:56 -0400 User-Agent: KMail/1.5.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304121548.56524.cbehanna@panasas.com> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cbehanna@panasas.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 19:48:59 -0000 On Saturday 12 April 2003 12:58, Dave Hart wrote: > Marko Zec said: > > Alfred Perlstein wrote: > > > * Marko Zec [030411 19:01] wrote: > > > > When enabled, the extended delaying policy introduces > > > > some additional changes: > > > > > > > > - fsync() no longer flushes the buffers to disk, but > > > > returns immediately instead; > > [...] > > > > Making fsync() not work is a good way to make any sort > > > of userland based transactional system break badly. > > [...] > > > If the disk would start spinning every now and than, > > the whole patch would than become pointless... > > As I feared. > > > [...] the fact that the modified fsync() just returns > > without doing anything useful doesn't mean the data will be > > lost - it will simply be delayed until the next coalesced > > updating occurs. > > Unless, of course, your system or power happens to fail. > Imagine you have a database program keeping track of banking > transactions. [...] Then you won't be running that program on a *laptop*, now, will you? It'll be in a NOC with hefty power-failover hardware already in place. Can we pretty please keep criticisms of this patch in their proper context? Power-saving features for a *laptop* have little or no bearing on the behavior of mission-critical back office applications. -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) behanna@bogus.zbzoom.net Turning coffee into software since 1990.