Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755789AbYLEB0k (ORCPT ); Thu, 4 Dec 2008 20:26:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752201AbYLEB0b (ORCPT ); Thu, 4 Dec 2008 20:26:31 -0500 Received: from one.firstfloor.org ([213.235.205.2]:34510 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752117AbYLEB0b (ORCPT ); Thu, 4 Dec 2008 20:26:31 -0500 Date: Fri, 5 Dec 2008 02:37:39 +0100 From: Andi Kleen To: Mikulas Patocka Cc: Andi Kleen , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, Alasdair G Kergon , Andi Kleen , Milan Broz Subject: Re: Device loses barrier support (was: Fixed patch for simple barriers.) Message-ID: <20081205013739.GZ6703@one.firstfloor.org> References: <20081204142015.GQ6703@one.firstfloor.org> <20081204145810.GR6703@one.firstfloor.org> <20081204174838.GS6703@one.firstfloor.org> <20081204221551.GV6703@one.firstfloor.org> <20081205004849.GX6703@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1485 Lines: 37 > * barrier support in md-raid1 deviates from the specification at > Documentation/block/barrier.txt. The specification says that requests > submitted after the barrier request hit the media after the barrier > request hits the media. The reality is that the barrier request can be > randomly aborted and the requests submitted after it hit the media before > the barrier request. Yes the spec should be probably updated. But also see Linus' rant from yesterday about code vs documentation. When in doubt the code wins. > > * the filesystems developed hacks to work around this issue, the hacks > involve not submitting more requests after the barrier request, I suspect the reason the file systems did it this way is that it was a much simpler change than to rewrite the transaction manager for this. > synchronously waiting for the barrier request and eventually retrying it. > These hacks suppress any performance advantage barriers could bring. > > * you submit a patch that makes barriers even more often deviate from the > specification and you argue that the patch is correct because filesystems > handle this deviation. Sorry what counts is the code behaviour, not the specification. -Andi -- ak@linux.intel.com -- 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/