From owner-freebsd-stable@FreeBSD.ORG Sun Apr 13 02:16:20 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 271DC37B401 for ; Sun, 13 Apr 2003 02:16:20 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BEAF43F93 for ; Sun, 13 Apr 2003 02:16:19 -0700 (PDT) (envelope-from metrol@metrol.net) Received: from metlap (adsl-67-121-60-9.dsl.anhm01.pacbell.net [67.121.60.9]) h3D9GH9e489324 for ; Sun, 13 Apr 2003 05:16:18 -0400 From: Michael Collette To: FreeBSD Mailing Lists Date: Sun, 13 Apr 2003 02:16:15 -0700 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304130216.15475.metrol@metrol.net> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 09:16:20 -0000 Jon Hamilton wrote: > 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. Despite criticism of Dave's comments, I'd also be a little concerned about what had been written to the drive prior to unexpected power loss. I'm saying this as a person who uses a laptop as my primary desktop machine. Real world laptop scenario. I just finish downloading my E-Mail. I then take and put this machine into a suspend mode. Upon awakening the system glitches for some reason forcing an unexpected system shutdown. (Note: I am having this problem now with a Thinkpad T23) Did my mail get written to the drive prior to suspending? I'll grant you that this isn't in the same league as moving cash around, but to me that mail is absolutely mission critical. I'd love to get 10% more battery life from my laptop, but not at the expense of having a file system that loses data on any unclean shutdown. Be it moving $500, storing E-Mail, or just saving a document I had been working on. With this patch in play when I tell an app to save a document will it? Later on, -- "Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." - Groucho Marx