On Tue, Apr 03, 2007 at 08:57:03AM -0700, Badari Pulavarty wrote: > On Tue, 2007-04-03 at 01:49 +0200, Nick Piggin wrote: > > > > 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). Hmm, I think we need better reclaim for buffers as well. That might help the problem. The thing that doesn't make sense with nobh is that you deliberately throw out buffers for dirty pages, which you know will be needed again for writeout. You also want to do as little work as possible in the writeout path (ie. do it all in the dirtying path) so as to avoid deadlocks and stuff. Anyway, I will keep nobh in mind. A port to the new aops shouldn't be impossible. > > 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. Well I'm just thinking we should all for it in the interface from the start, so that if we ever have a need to error out there, we can without having to update all filesystems. I can't imagine a reason today though... - 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
