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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
