From owner-freebsd-fs@FreeBSD.ORG Sat Apr 12 10:24:57 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9EE537B401; Sat, 12 Apr 2003 10:24:57 -0700 (PDT) Received: from mail4.wi.rr.com (fe4.rdc-kc.rr.com [24.94.163.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A1143FAF; Sat, 12 Apr 2003 10:24:56 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.nethamilton.net ([65.25.186.233]) by mail4.wi.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 12 Apr 2003 12:24:21 -0500 Received: by woodstock.nethamilton.net (Postfix, from userid 500) id 2432144EA; Sat, 12 Apr 2003 12:24:55 -0500 (CDT) Date: Sat, 12 Apr 2003 12:24:55 -0500 From: Jon Hamilton To: Dave Hart Message-ID: <20030412172455.GA85377@woodstock.nethamilton.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-fs@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 17:24:58 -0000 Dave Hart , said on Sat Apr 12, 2003 [04:58:13 PM]: } Marko Zec said: [...] } > 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. This program uses fsync() to ensure its } transaction logs are committed to reliable storage before } indicating the transaction is completed. Suppose the moment } after I withdraw $500 from an ATM, the operating system or } hardware fails at the bank. Right. So in such a situation, the admin for that system would not enable this optional behavior. There probably aren't too many cases where mission critical financial transaction systems run on a laptop on which the desire is maximal battery life, which is the case from which this whole patch/discussion derives. It's a conscious tradeoff. -- Jon Hamilton hamilton@pobox.com