From owner-freebsd-fs@FreeBSD.ORG Sat Apr 12 11:54:05 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 B8FE437B401 for ; Sat, 12 Apr 2003 11:54:05 -0700 (PDT) Received: from bilver.wjv.com (user38.net339.fl.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A540443FCB for ; Sat, 12 Apr 2003 11:54:03 -0700 (PDT) (envelope-from bv@wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by bilver.wjv.com (8.12.9/8.12.9) with ESMTP id h3CIrmab061442 for ; Sat, 12 Apr 2003 14:53:49 -0400 (EDT) (envelope-from bv@wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.9/8.12.9/Submit) id h3CIrlQc061429 for freebsd-fs@freebsd.org; Sat, 12 Apr 2003 14:53:47 -0400 (EDT) Date: Sat, 12 Apr 2003 14:53:46 -0400 From: Bill Vermillion To: freebsd-fs@freebsd.org Message-ID: <20030412185346.GB52650@wjv.com> References: <20030412172455.GA85377@woodstock.nethamilton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030412172455.GA85377@woodstock.nethamilton.net> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,NIGERIAN_TRANSACTION_1,NOSPAM_INC, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT version=2.43 Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bv@wjv.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 18:54:06 -0000 In the last exciting episode of the Jon Hamilton saga on Sat, Apr 12, 2003 at 12:24 , Jon Hamilton as heard to say: > 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. I think 'the admin could enable this optional behaviour' is the wrong approach. I think it should be for laptops the admin could >disable< the feature. By default make everyting as robust and failsafe as possible. In the past enable options aren't always enabled when they should be. Default to secure and stable and let the admins change it. Bill -- Bill Vermillion - bv @ wjv . com