From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Merge window closed - 2.6.39-rc1 out
Date: Fri, 1 Apr 2011 09:17:13 -0400 [thread overview]
Message-ID: <20110401131713.GA16734@dumpdata.com> (raw)
In-Reply-To: <20110330222909.GA26174@infradead.org>
On Wed, Mar 30, 2011 at 06:29:09PM -0400, Christoph Hellwig wrote:
> (1) it still has the totally stupid interface of a global dispatch table.
> Either it does make sense to have different providers, in which
> case you want the dispatch table on a per-superblock or whatever
> granularity, or you really want just one and can have static calls
> into it, and get rid of this whole layer
> (2) it still requires totally pointless calls from local filesystem to
> initialize a pool ID. The filesystem really should not need to
> care about any of this.
Thank you for taking a look at the patches. I think what you are saying
is that the opt-in interface (where only those fs that want it) are using,
is not proper. It should be in for everybody? Hmm.. let me ponder this.
> (3) it's still lacking a good user submitted with it. And with that
> I don't mean junk code shoved into staging where it's bitrotting.
I think when one takes user cases and try to use one type of matrix (say,
how many customers are using it) but use another (how many enterprise
clients are clamoring for it) you get drastically different numbers.
If you just use one ruler to evaluate acceptance, then maybe
unicore32 (just one company), or ILO (small community compared to SCST)
should have not been merged b/c of that? But if you think of other
acceptance rules then it makes sense.
>
> It also has an entirely new bug, in that it assumes every inode has
> a dentry on the alias list. Did you only ever test this with filesystem
> that do not have export operations? Otherwise the no-dentry case should
> be fairly trivial to trigger due the placement of the hooks.
Aha! Thank you for spotting that. Dan did post a patch for this:
https://lkml.org/lkml/2011/3/3/291
And he should have pulled it in his tree <sigh> Will ask him to create
a branch with this bug-fix.
>
> And of course there's still no convincing use case for all of this.
next prev parent reply other threads:[~2011-04-01 13:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 21:07 Merge window closed - 2.6.39-rc1 out Linus Torvalds
2011-03-30 12:01 ` Christoph Hellwig
2011-03-30 14:43 ` Konrad Rzeszutek Wilk
2011-03-30 15:05 ` Konrad Rzeszutek Wilk
2011-03-30 22:29 ` Christoph Hellwig
2011-04-01 13:17 ` Konrad Rzeszutek Wilk [this message]
2011-03-30 22:20 ` [PATCH -rc1] msi-laptop: fix config-dependent build error Randy Dunlap
2011-03-31 6:41 ` Joey Lee
2011-04-01 18:21 ` Matthew Garrett
2011-03-31 2:17 ` Merge window closed - 2.6.39-rc1 out Rusty Russell
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=20110401131713.GA16734@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox