On Mon, 2014-06-23 at 17:27 -0700, Daniel Phillips wrote:
> On Sunday, June 22, 2014 7:43:07 AM PDT, James Bottomley wrote:
> > On Sat, 2014-06-21 at 20:32 -0700, Daniel Phillips wrote:
> >> On Saturday, June 21, 2014 12:29:01 PM PDT, James Bottomley wrote:
> >>> That's a bit disingenuous: the concern has always been how page forking
> >>> interacted with writeback. It's not new, it was one of the major
> things
> >>> brought up at LSF 14 months ago, so you weren't just assigned this.
> > ...
> >>
> >> [citation needed]
> >
> > Really? I was there; I remember and it's in my notes of the discussion.
> > However, it's also in Jon's at paragraph 6 if you need to refer to
> > something to refresh your memory.
>
> You have such a wonderfully charismatic way of providing citations.
Well, it's factual, as I presume you have now discovered.
> > However, when it was spotted isn't the issue; how we add tux3 without a
> > large maintenance burden on writeback is, as I carefully explained in
> > the rest of the email you cut.
>
> You are doing a fine job of proving to the world that LKML has become
> a toxic waste dump. CC to LKML removed for obvious reasons.
Please don't drop the Mailing list cc; that's where the debate actually
happens and where others can see it.
> Please let this be the end of the unhelpful rhetoric that does none of us any
> good, especially you.
Telling you factually what the issue is isn't rhetoric. Your Ad Hominem
reply, of course, is rhetoric but I don't need to bother engaging with
your rhetorical technique because I'm still arguing the facts: proving
that page forking can be integrated into writeback without adding to the
maintenance burden is a big issue for tux3. We're all still waiting for
the patches you were going to produce showing how this could be done.
James
On Monday, June 23, 2014 9:41:30 PM PDT, James Bottomley wrote:
>
> [rhetoric snipped]
>
> ... I'm still arguing the facts: proving
> that page forking can be integrated into writeback without adding to the
> maintenance burden is a big issue for tux3.
Sorry, I must have missed those facts, I only saw recycled opinions.
> We're all still waiting for the patches you were going to produce
> showing how this could be done.
That makes sense, because the patches to transform our workarounds
into shiny new kernel hooks are still in progress, as I said. I would
appreciate the courtesy of being permitted to take the time to do the
work to the necessary quality without being subjected to endless
carping about when the patches will be posted.
If there is genuine interest in how we are approaching the new mm
hooks for page forking I will happily to take the time to discuss
it.
Note that I do not complain about Dave Chinner's endless carping, which
contains much the same rhetoric as your posts, the difference being that
Dave has proved himself a good reviewer. Though Dave behaves as caustically
as you or perhaps more so, he always takes care to provide just enough
useful technical sweetener to keep the technical vs toxic balance on the
positive side. Of course, it would be much better for all if he cared to
adopt a collegial manner, like Ted for example, who incidentally can flame
with the best of them when he wants to. But who would want to, other than a
self obsessed moron?
Speaking of Dave, what would be really interesting at this point is the
long
story of how XFS worked around pretty nearly the same writeback issues that
Tux3 does. We already saw the short story, but it went by pretty fast.
Color
me truly interested, in part because a good solution to this is probably
what
we really want for writeback. Not immediately, because re-engineering parts
of
core kernel unnecessarily during a filesystem merge is simply foolhardy,
but
at some time in the not too distant future. (CC to Dave added.)
Regards,
Daniel
On Tue, Jun 24, 2014 at 02:10:52AM -0700, Daniel Phillips wrote:
>
> That makes sense, because the patches to transform our workarounds
> into shiny new kernel hooks are still in progress, as I said. I would
> appreciate the courtesy of being permitted to take the time to do the
> work to the necessary quality without being subjected to endless
> carping about when the patches will be posted.
The feedback which you have been getting, fairly consistently I
believe, is that it is the shiny new kernel hooks that need to be
reviewed, not the workarounds. I don't think it's a matter of people
not being willing to give you the time to do this work (take all the
time you need!); but rather that it's premature for you to be asking
for tux3 to be merged before those patches have been posted and
reviewed and found to be shiny.
Best regards,
- Ted
On Tuesday, June 24, 2014 3:59:40 AM PDT, Theodore Ts'o wrote:
> On Tue, Jun 24, 2014 at 02:10:52AM -0700, Daniel Phillips wrote:
>>
>> That makes sense, because the patches to transform our workarounds
>> into shiny new kernel hooks are still in progress, as I said. I would
>> appreciate the courtesy of being permitted to take the time to do the
>> work to the necessary quality without being subjected to endless
>> carping about when the patches will be posted.
>
> The feedback which you have been getting, fairly consistently I
> believe, is that it is the shiny new kernel hooks that need to be
> reviewed, not the workarounds. I don't think it's a matter of people
> not being willing to give you the time to do this work (take all the
> time you need!); but rather that it's premature for you to be asking
> for tux3 to be merged before those patches have been posted and
> reviewed and found to be shiny.
That is not quite right. Before posted the filesystem for review,
we did not know whether core changes or workarounds would be the
better route. Now we do know, and have duly turned our coding
energy to producing a set of decent core hooks. That does not mean
that we are taking Tux3 "out of play". That would just be stupid.
I emphatically disagree that it is premature for asking Tux3 to be
merged. You might think so, but I do not. While I do not begrudge
you your opinion, Linux did not get to the dominant position it has
today by being shy about merging new functionality early. Did we
suddenly lose our mojo just at Tux3 merge time?
If you really think that Tux3 has been offered for merge too early,
then clone our tree, build it, break it and heap abuse on us. That
should take you about one hour if you are right.
Regards,
Daniel
On Tue, 2014-06-24 at 04:27 -0700, Daniel Phillips wrote:
> On Tuesday, June 24, 2014 3:59:40 AM PDT, Theodore Ts'o wrote:
> > On Tue, Jun 24, 2014 at 02:10:52AM -0700, Daniel Phillips wrote:
> >>
> >> That makes sense, because the patches to transform our workarounds
> >> into shiny new kernel hooks are still in progress, as I said. I would
> >> appreciate the courtesy of being permitted to take the time to do the
> >> work to the necessary quality without being subjected to endless
> >> carping about when the patches will be posted.
> >
> > The feedback which you have been getting, fairly consistently I
> > believe, is that it is the shiny new kernel hooks that need to be
> > reviewed, not the workarounds. I don't think it's a matter of people
> > not being willing to give you the time to do this work (take all the
> > time you need!); but rather that it's premature for you to be asking
> > for tux3 to be merged before those patches have been posted and
> > reviewed and found to be shiny.
>
> That is not quite right. Before posted the filesystem for review,
> we did not know whether core changes or workarounds would be the
> better route. Now we do know, and have duly turned our coding
> energy to producing a set of decent core hooks. That does not mean
> that we are taking Tux3 "out of play". That would just be stupid.
OK, but now we've explained the reason several times: The original set
of hacks is fragile against changes to writeback, which is the
maintenance problem.
> I emphatically disagree that it is premature for asking Tux3 to be
> merged. You might think so, but I do not. While I do not begrudge
> you your opinion, Linux did not get to the dominant position it has
> today by being shy about merging new functionality early. Did we
> suddenly lose our mojo just at Tux3 merge time?
But you've agreed to go the core hooks route, the patches for which
aren't yet ready, so what is there actually to review and merge until
the patches appear?
James
> If you really think that Tux3 has been offered for merge too early,
> then clone our tree, build it, break it and heap abuse on us. That
> should take you about one hour if you are right.
>
> Regards,
>
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, June 24, 2014 4:52:15 AM PDT, James Bottomley wrote:
> On Tue, 2014-06-24 at 04:27 -0700, Daniel Phillips wrote:
>> I emphatically disagree that it is premature for asking Tux3 to be
>> merged. You might think so, but I do not. While I do not begrudge
>> you your opinion, Linux did not get to the dominant position it has
>> today by being shy about merging new functionality early. Did we
>> suddenly lose our mojo just at Tux3 merge time?
>
> But you've agreed to go the core hooks route, the patches for which
> aren't yet ready, so what is there actually to review and merge until
> the patches appear?
If Linus asks for a Tux3 pull first thing tomorrow we will agree to
it, perfect core patches or not. This is because we are confident
that all remaining API issues and code duplication issues are
solvable in the usual Linux way. The Tux3 tree exactly as posted
builds and runs passing well. We do not feel ashamed of it at all,
quite the contrary.
Mind you, we know that everybody is looking forward to a lively
discussion about page forking, as well they should. But it does not
really matter whether that takes place before or after merge. You
know as well as I do that we are collectively smart enough to make
it work, and you probably understand by now why it is worth making
it work. Further, we think it already works, both by analysis and
empirical results of our stress testing.
If you have a _specific_ example of an API issue that is not solvable
in the usual Linux way, please share it.
Regards,
Daniel