Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757083AbYLEC6h (ORCPT ); Thu, 4 Dec 2008 21:58:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752177AbYLEC63 (ORCPT ); Thu, 4 Dec 2008 21:58:29 -0500 Received: from one.firstfloor.org ([213.235.205.2]:33787 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbYLEC63 (ORCPT ); Thu, 4 Dec 2008 21:58:29 -0500 Date: Fri, 5 Dec 2008 04:09:38 +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: <20081205030938.GA6703@one.firstfloor.org> References: <20081204145810.GR6703@one.firstfloor.org> <20081204174838.GS6703@one.firstfloor.org> <20081204221551.GV6703@one.firstfloor.org> <20081205004849.GX6703@one.firstfloor.org> <20081205013739.GZ6703@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: 1324 Lines: 39 > The only one offender is "md". I'm not sure. It wouldn't surprise me if it can happen with other setups too. Perhaps Chris knows more. > It is less overhead to change "md" to play > nice and be reliable than to double-submit requests in all the places that > needs write ordering. They do that already anyways. > > > > * 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. > > It could be initial reason. But this unreliability also disallows any > improvement in filesystems. No one can write asynchronous transaction > manager because of that evil EOPNOTSUPP. Doesn't seem right. It would be a simple state machine to handle it fully asynchronous. Alternatively you could always use empty barriers. But we can worry about that when some in tree file system actually tries to do that. -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/