All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Badari Pulavarty <pbadari@gmail.com>
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: Wed, 4 Apr 2007 04:31:09 +0200	[thread overview]
Message-ID: <20070404023109.GA18507@wotan.suse.de> (raw)
In-Reply-To: <1175615824.24533.31.camel@dyn9047017100.beaverton.ibm.com>

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...

  reply	other threads:[~2007-04-04  2:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02 12:09 [ANNOUNCE] new new aops patchset Nick Piggin
2007-04-02 20:18 ` Badari Pulavarty
2007-04-03  0:45   ` Nick Piggin
2007-04-02 20:44 ` Badari Pulavarty
2007-04-02 23:58   ` Nick Piggin
2007-04-03 15:59     ` Badari Pulavarty
2007-04-04  2:33       ` Nick Piggin
2007-04-02 21:44 ` Badari Pulavarty
2007-04-02 23:08 ` Badari Pulavarty
2007-04-02 23:14 ` Badari Pulavarty
2007-04-02 23:49   ` Nick Piggin
2007-04-03 15:57     ` Badari Pulavarty
2007-04-04  2:31       ` Nick Piggin [this message]
2007-04-02 23:31 ` Badari Pulavarty
2007-04-02 23:35   ` Nick Piggin
2007-04-02 23:56 ` Badari Pulavarty
2007-04-03  0:02   ` Nick Piggin
2007-04-03  0:00 ` Badari Pulavarty
2007-04-03  0:08   ` Nick Piggin
2007-04-03  9:31     ` Nick Piggin
2007-04-03 16:03       ` Badari Pulavarty
2007-04-04  2:37         ` Nick Piggin
2007-04-03 17:35 ` Badari Pulavarty
2007-04-04  3:05   ` Nick Piggin
2007-04-04 22:10 ` Mark Fasheh
2007-04-04 22:39   ` Badari Pulavarty
2007-04-04 22:51     ` Mark Fasheh
2007-04-04 23:02       ` Badari Pulavarty
2007-04-04 23:05   ` Badari Pulavarty
2007-04-04 23:17     ` Mark Fasheh
2007-04-04 23:32       ` Badari Pulavarty
2007-04-05  2:08         ` Nick Piggin
2007-04-05 15:21           ` Badari Pulavarty
2007-04-06  1:38             ` Nick Piggin
2007-04-05  2:09   ` Nick Piggin
2007-04-05  0:10 ` David Chinner
2007-04-05  2:13   ` Nick Piggin
2007-04-05  7:45     ` Christoph Hellwig
2007-04-05  7:58       ` Nick Piggin
2007-04-05  2:43   ` David Chinner
2007-04-05  3:00     ` Nick Piggin
2007-04-05  6:18       ` David Chinner
2007-04-05  6:40         ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070404023109.GA18507@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mark.fasheh@oracle.com \
    --cc=pbadari@gmail.com \
    --cc=swhiteho@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.