Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760885AbZC3UUU (ORCPT ); Mon, 30 Mar 2009 16:20:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760872AbZC3UTx (ORCPT ); Mon, 30 Mar 2009 16:19:53 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]:60584 "EHLO acsinet12.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760836AbZC3UTv (ORCPT ); Mon, 30 Mar 2009 16:19:51 -0400 Subject: Re: [PATCH 1/7] block: Add block_flush_device() From: Chris Mason To: Andi Kleen Cc: Jeff Garzik , Jens Axboe , Linus Torvalds , Fernando Luis =?ISO-8859-1?Q?V=E1zquez?= Cao , Christoph Hellwig , Theodore Tso , Ingo Molnar , Alan Cox , Arjan van de Ven , Andrew Morton , Peter Zijlstra , Nick Piggin , David Rees , Jesper Krogh , Linux Kernel Mailing List , david@fromorbit.com, tj@kernel.org In-Reply-To: <87ljqmlqm5.fsf@basil.nowhere.org> References: <20090329082507.GA4242@infradead.org> <49D01F94.6000101@oss.ntt.co.jp> <49D02328.7060108@oss.ntt.co.jp> <49D0258A.9020306@garzik.org> <49D03377.1040909@oss.ntt.co.jp> <49D0B535.2010106@oss.ntt.co.jp> <49D0B687.1030407@oss.ntt.co.jp> <20090330175544.GX5178@kernel.dk> <20090330185414.GZ5178@kernel.dk> <49D11A8D.1090600@garzik.org> <1238441043.20607.16.camel@think.oraclecorp.com> <87ljqmlqm5.fsf@basil.nowhere.org> Content-Type: text/plain Date: Mon, 30 Mar 2009 16:15:08 -0400 Message-Id: <1238444108.25199.2.camel@think.oraclecorp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 Content-Transfer-Encoding: 7bit X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.49D12853.003F:SCFMA4539814,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1347 Lines: 32 On Mon, 2009-03-30 at 22:09 +0200, Andi Kleen wrote: > Chris Mason writes: > > > > As far as I know, reiserfs is the only one actively using it to choose > > different code. It moves a single wait_on_buffer when barriers are on, > > which I took out once to simplify the code. Ric saw it in some > > benchmark numbers and I put it back in. > > > > Given that it was a long time ago, I don't have a problem with changing > > it to work like all the other filesystems. > > When it was a win on reiserfs back then maybe it would be a win > on ext4 or xfs today too? It could be, but you get into some larger changes. The theory behind the code was that writeback cache is on, so wait_on_buffer isn't really going to give you a worthwhile error return anyway. Might as well do the wait_on_buffer some time later and fix up the commit blocks if it didn't work out. We're still arguing about barriers being a good idea all these years later, and the drives are better at them than they used to be. So, I'd rather see less complex code in the filesystems than more. -chris -- 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/