Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751623AbXE2XtV (ORCPT ); Tue, 29 May 2007 19:49:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751053AbXE2XtI (ORCPT ); Tue, 29 May 2007 19:49:08 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:45078 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750744AbXE2XtG (ORCPT ); Tue, 29 May 2007 19:49:06 -0400 Date: Wed, 30 May 2007 09:48:32 +1000 From: David Chinner To: Phillip Susi Cc: David Chinner , Neil Brown , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, Jens Axboe , Stefan Bader , Andreas Dilger , Tejun Heo Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md. Message-ID: <20070529234832.GT85884050@sgi.com> References: <18006.38689.818186.221707@notabene.brown> <18010.12472.209452.148229@notabene.brown> <20070528024559.GA85884050@sgi.com> <465C871F.708@cfl.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C871F.708@cfl.rr.com> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1608 Lines: 44 On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote: > David Chinner wrote: > >The use of barriers in XFS assumes the commit write to be on stable > >storage before it returns. One of the ordering guarantees that we > >need is that the transaction (commit write) is on disk before the > >metadata block containing the change in the transaction is written > >to disk and the current barrier behaviour gives us that. > > Barrier != synchronous write, Of course. FYI, XFS only issues barriers on *async* writes. But barrier semantics - as far as they've been described by everyone but you indicate that the barrier write is guaranteed to be on stable storage when it returns. > so if XFS relies on that block being on > the media when the request is completed, then it is broken. XFS relies on the block being stable before any other write goes to disk. That is the semantic that the barrier I/Os currently have. How that is implemented in the device is irrelevant to me, but if I issue a barrier I/O, I do not expect *any* I/O to be reordered around it. > It should > only care that the ordering of log-data-log is maintained, not exactly > when each specific request completes. Yes, and that is provided to XFS by the fact that barrier I/Os are full barriers.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/