From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md. Date: Mon, 04 Jun 2007 16:39:45 +0900 Message-ID: <4663C1C1.5000009@gmail.com> References: <20070530061723.GY85884050@sgi.com> <20070531002011.GC85884050@sgi.com> <20070531062644.GI32105@kernel.dk> <20070531070307.GK85884050@sgi.com> <20070531070656.GK32105@kernel.dk> <465F8F71.20302@gmail.com> <20070601082140.GP32105@kernel.dk> <46613666.7010800@gmail.com> <20070602143438.GB32105@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Chinner , david@lang.hm, Phillip Susi , Neil Brown , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, Stefan Bader , Andreas Dilger To: Jens Axboe Return-path: Received: from nz-out-0506.google.com ([64.233.162.229]:23290 "EHLO nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752139AbXFDHj7 (ORCPT ); Mon, 4 Jun 2007 03:39:59 -0400 Received: by nz-out-0506.google.com with SMTP id n1so927086nzf for ; Mon, 04 Jun 2007 00:39:59 -0700 (PDT) In-Reply-To: <20070602143438.GB32105@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jens Axboe wrote: > On Sat, Jun 02 2007, Tejun Heo wrote: >> Hello, >> >> Jens Axboe wrote: >>>> Would that be very different from issuing barrier and not waiting for >>>> its completion? For ATA and SCSI, we'll have to flush write back cache >>>> anyway, so I don't see how we can get performance advantage by >>>> implementing separate WRITE_ORDERED. I think zero-length barrier >>>> (haven't looked at the code yet, still recovering from jet lag :-) can >>>> serve as genuine barrier without the extra write tho. >>> As always, it depends :-) >>> >>> If you are doing pure flush barriers, then there's no difference. Unless >>> you only guarantee ordering wrt previously submitted requests, in which >>> case you can eliminate the post flush. >>> >>> If you are doing ordered tags, then just setting the ordered bit is >>> enough. That is different from the barrier in that we don't need a flush >>> of FUA bit set. >> Hmmm... I'm feeling dense. Zero-length barrier also requires only one >> flush to separate requests before and after it (haven't looked at the >> code yet, will soon). Can you enlighten me? > > Yeah, that's what the zero-length barrier implementation I posted does. > Not sure if you have a question beyond that, if so fire away :-) I thought you were talking about adding BIO_RW_ORDERED instead of exposing zero length BIO_RW_BARRIER. Sorry about the confusion. :-) -- tejun