From: Pavel Machek <pavel@ucw.cz>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Daniel Phillips <daniel@phunq.net>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC] Tux3 for review
Date: Thu, 19 Jun 2014 10:21:29 +0200 [thread overview]
Message-ID: <20140619082129.GA4309@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <1402932354.2197.61.camel@dabdike.int.hansenpartnership.com>
On Mon 2014-06-16 08:25:54, James Bottomley wrote:
> On Sun, 2014-06-15 at 14:41 -0700, Daniel Phillips wrote:
> > On Friday, June 13, 2014 1:20:39 PM PDT, Pavel Machek wrote:
> > > On Fri 2014-06-13 10:49:39, Daniel Phillips wrote:
> > to sign up for a ridiculous amount of largely thankless, but
> > perhaps fascinating work. Any volunteers?
>
> The whole suggestion is a non starter: we can't stage core API changes.
> Even if we worked out how to do that, the staging trees mostly don't get
> the type of in-depth expert review that you need anyway.
Well.. most filesystems do not need any core API changes, right?
> The Cardinal concern has always been the viability page forking and its
> impact on writeback ... and since writeback is our most difficult an
> performance sensitive area, the bar to changing it is high.
And in this particular case, Daniel was flamed for poor coding style, not
for page forking. So staging/ would actually help him -- he could concentrate
on core changes without being distracted by unimportant stuff.
> When you presented page forking at LSF/MM in 2013, it didn't even stand
> up to basic scrutiny before people found unresolved problems:
>
> http://lwn.net/Articles/548091/
>
> After lots of prodding, you finally coughed up a patch for discussion:
>
> http://thread.gmane.org/gmane.linux.file-systems/85619
>
> But then that petered out again. I can't emphasise enough that
> iterating these threads to a conclusion and reposting interface
> suggestions is the way to proceed on this ... as far as I can tell from
> the discussion, the reviewers were making helpful suggestions, even if
> they didn't like the original interface you proposed.
This obviously needs to be solved, first...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2014-06-19 8:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-17 0:50 Daniel Phillips
2014-05-17 5:09 ` Martin Steigerwald
2014-05-17 5:29 ` Daniel Phillips
2014-05-20 6:56 ` Daniel Phillips
2014-05-18 23:55 ` Dave Chinner
2014-05-20 0:55 ` Daniel Phillips
2014-05-20 3:18 ` Dave Chinner
2014-05-20 5:41 ` Daniel Phillips
2014-05-20 17:25 ` Daniel Phillips
2014-06-13 10:32 ` Pavel Machek
2014-06-13 17:49 ` Daniel Phillips
2014-06-13 20:20 ` Pavel Machek
2014-06-15 21:41 ` Daniel Phillips
2014-06-16 15:25 ` James Bottomley
2014-06-19 8:21 ` Pavel Machek [this message]
2014-06-19 9:26 ` Lukáš Czerner
2014-06-19 21:58 ` Daniel Phillips
2014-06-21 19:29 ` James Bottomley
2014-06-22 1:06 ` Dave Chinner
2014-06-24 11:16 ` Daniel Phillips
2014-06-22 3:32 ` Daniel Phillips
2014-06-22 14:43 ` James Bottomley
[not found] ` <522aee97-34e7-4adc-adf2-c9b73aa0ef36@phunq.net>
2014-06-24 4:41 ` James Bottomley
2014-06-24 9:10 ` Daniel Phillips
2014-06-24 10:59 ` Theodore Ts'o
2014-06-24 11:27 ` Daniel Phillips
2014-06-24 11:52 ` James Bottomley
2014-06-24 12:10 ` Daniel Phillips
2014-06-22 18:34 ` Theodore Ts'o
2014-06-24 0:31 ` Daniel Phillips
2014-06-24 0:19 ` Daniel Phillips
2014-05-22 9:52 ` Dongsu Park
2014-05-23 8:21 ` Daniel Phillips
2014-06-19 16:24 ` Josef Bacik
2014-06-19 22:14 ` Daniel Phillips
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=20140619082129.GA4309@xo-6d-61-c0.localdomain \
--to=pavel@ucw.cz \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@phunq.net \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.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
all inboxes | Powered by JetHome®