From owner-freebsd-fs@FreeBSD.ORG Fri Dec 2 02:36:30 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BB7C106564A; Fri, 2 Dec 2011 02:36:30 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) by mx1.freebsd.org (Postfix) with ESMTP id 416FA8FC17; Fri, 2 Dec 2011 02:36:30 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id pB22aQi6059579; Thu, 1 Dec 2011 18:36:26 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201112020236.pB22aQi6059579@chez.mckusick.com> To: Pawel Jakub Dawidek In-reply-to: <20111125110235.GB1642@garage.freebsd.pl> Date: Thu, 01 Dec 2011 18:36:26 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com Cc: freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 02:36:30 -0000 > Date: Fri, 25 Nov 2011 12:02:35 +0100 > From: Pawel Jakub Dawidek > To: Kostik Belousov > Cc: freebsd-fs@freebsd.org > Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with > softupdates)? > > On Wed, Nov 23, 2011 at 09:44:44PM +0200, Kostik Belousov wrote: > > On Wed, Nov 23, 2011 at 11:00:26PM +0400, Lev Serebryakov wrote: > > > Hello, Freebsd-fs. > > >=20 > > > Does UFS2 with softupdates (without journal) issues BIO_FLUSH to > > > GEOM layer when it need to ensure consistency on on-disk metadata? > > No. Softupdates do not need flushes. > > Well, they do for two reasons: > 1. To properly handle sync operations (fsync(2), O_SYNC). > 2. To maintain consistent on-disk structures. SU does not use synchronous writes to maintain consistency (see below). It rarely uses synchronous writes even to immplement fsync. Instead it issues async I/O requests for all the blocks necessary to ensure that the inode in question is stable. It then waits until all of those writes have been acknowledged. When they have been acknowledged the fsync returns. If the subsystem acknowledges them before they are truely on stable store, then SU and correspondingly the caller of fsync is screwed. The one place where a synchronous write (bwrite) is used is when the completion of a particular I/O is needed to make progress on many other things (usually an update to the SUJ log) in which case SU will force a flush on that I/O (e.g., bwrite it) to hasten it along. > The second point is there, because BIO_FLUSH is the only way to avoid > reordering (apart from turning off disk write cache). > > SU assumes no I/O reordering will happen, which is very weak assumption. > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://yomoli.com SU has no problems with reordering. It makes no assumptions on the order in which its I/O operations are done. Its only requirement is that it not be told that something is stable before it truely is stable. Because the way that it maintains consistency is to not issue a write on something before it knows that something that it depends on for consistency is in fact stable. But it has no problem with any of its outstanding writes being done in any particular order. Kirk McKusick