Re: [ANNOUNCE] new new aops patchset

From: Badari Pulavarty <pbadari@gmail.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Filesystems <linux-fsdevel@vger.kernel.org>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: [ANNOUNCE] new new aops patchset
Date: Tue, 03 Apr 2007 08:57:03 -0700	[thread overview]
Message-ID: <1175615824.24533.31.camel@dyn9047017100.beaverton.ibm.com> (raw)
In-Reply-To: <20070402234932.GC12295@wotan.suse.de>

On Tue, 2007-04-03 at 01:49 +0200, Nick Piggin wrote:
> On Mon, Apr 02, 2007 at 04:14:59PM -0700, Badari Pulavarty wrote:
> > On Mon, 2007-04-02 at 14:09 +0200, Nick Piggin wrote:
> > > Updated aops patchset against 2.6.21-rc5.
> > > 
> > > http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
> > > 
> > > Files/dirs are 2.6.21-rc5-new-aops*
> > 
> > Baaah !! You took away ext3 -nobh option :(
> 
> Ahh, just the person I wanted to ask! ;) How useful is it, out of curiosity?
> What sort of users use it, and what sort of improvements do they get?

Well, at the time it helped lowmem issue on x86. Bufferheads end up
using lots of lowmem and caused bunch of issues. We used it heavily
on our local machines. Not sure if any customers use it (my guess
is not).

I wanted to completely kill bufferhead usage from ext3. writeback
mode is simple and easy. Ordered mode, need attach the buffers
to transaction - which needed complete rework. So never gotten
around to doing it.

> 
> > Do you have plans to support nobh versions of block_write_begin/end ?
> 
> At the moment I'm looking at doing it another way. Having the seperate
> nobh path is quite annoying -- there are still bugs in it and it is
> simply less tested (not that the bh path is bug-free either, but it
> is better to be able to concentrate on one). So I hope to merge them
> at some point to restore that functionality. 
> 
> 
> > BTW, I don't see how block_write_end() can ever return < 0.
> > If so, here is the cleanup fix for ext3 (no unnecessay checks).
> 
> Shouldn't we allow for the possibility?

Well, if there is a (remote) possibility of failure - yes
we should handle it. Otherwise its dead code, unnecessary
checks in hotpath and makes code ugly by confusing non-possible
error cases from possible ones. 

Even today - ext3 code has checks to handle  generic_commit_write()
failures. But it never returns failure. I wanted to clean up ext3 code,
but I left it for allowing for possibility.

Thanks,
Badari