From owner-freebsd-stable@FreeBSD.ORG Sat Apr 12 09:58:15 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 44E9637B401; Sat, 12 Apr 2003 09:58:15 -0700 (PDT) Received: from OLYMPIC.AD.HartBrothers.Com (olympic.ad.hartbrothers.com [63.102.100.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9547F43FAF; Sat, 12 Apr 2003 09:58:14 -0700 (PDT) (envelope-from davehart@davehart.com) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Date: Sat, 12 Apr 2003 16:58:13 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PATCH: Forcible delaying of UFS (soft)updates Thread-Index: AcMBD+R/0P6Gl+PfRL69GhtFtTaURAAAnvQA From: "Dave Hart" To: , cc: mckusick@McKusick.COM cc: Alfred Perlstein 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: Sat, 12 Apr 2003 16:58:15 -0000 Marko Zec said: > Alfred Perlstein wrote: >=20 > > * Marko Zec [030411 19:01] wrote: > > > > > > When enabled, the extended delaying policy introduces=20 > > > some additional changes: > > > > > > - fsync() no longer flushes the buffers to disk, but=20 > > > 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=20 > 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. With your change to fsync() to not commit to stable storage, I may have just won $500 courtesy of you. That is, the database software did all it could to ensure the $500 transaction was actually written to disk before authorizing the ATM to dispense cash, yet fsync() has decided it's not that important to do right away, so the transaction might well have not hit the disk before the catastrophe. For a perspective from the Windows world on the same sort of capability, check out the Win32 FlushFileBuffers spec: http://makeashorterlink.com/?E26B12F24 which is an alias for: http://msdn.microsoft.com/library/default.asp?url=3D/library/ en-us/fileio/base/flushfilebuffers.asp >From that page: "The FlushFileBuffers function writes all=20 of the buffered information for the specified file to disk." Such is the world of writing OS code -- optimizing for one situation may well break other important uses of the same code. Regards, Dave Hart davehart@davehart.com (who spent more time formatting text than writing, sigh)