On 12/17/2010 12:11 PM, Chuck Lever wrote:
On Dec 16, 2010, at 10:32 PM, Trond Myklebust wrote:
On Thu, 2010-12-16 at 18:40 -0500, Christoph Hellwig wrote:
On Thu, Dec 16, 2010 at 06:30:34PM -0500, Ric Wheeler wrote:
This has nothing to do with shame or conspiracy, it has to do with
doing changes in an orderly way so we can test and stabilize things
in the upstream kernel.
Changing both at once is not good for upstream or distros in my opinion,
Steve's mail reads pretty different from that.
But it doesn't really matter as it doesn't make any sense - as Chuck
has explained theres zero overlap between the XDR decoder changes and
pnfs features anyway. And if there was it's pretty clear something that
the about 98% of the userbase that's using NFSv3 uses should have more
priority over the 0.5% that are planning to maybe possibly use pnfs in
the next decade.
Hi guys,
I agree 100% with the basic premise that we should not have to deal with
compatibility issues for NFSv4.1/pnfs backports when deciding what to
merge upstream.
That said: as far as I can see, pretty much all these changes are
confined to the NFSv2 and NFSv3 XDR code. I can quite understand why
distros like Red Hat, SuSE, Debian, and others might want to avoid
having to back port changes, given that the NFSv2 and NFSv3 code bases
are supposed to be fully stable and frozen.
So my questions to Steve and Ric are:
1. Specifically, which part of these changes are causing
backporting headaches for the RHEL-6 code base? Note that when
asking that question I am assuming that Red Hat will triage and
reject patches that conflict with their stability goals.
2. Could we set up some minimal set of patches that would allow the
pNFS backport while avoiding the need for a full backport of
Chuck's patches for NFSv2/v3? If so, what features do we need,
and what is not needed?
IOW: how can we refactor these patches so as to avoid tying the set of
NFSv2/v3 changes to any pNFS interests?
My reading of Ric's concern is that RH doesn't have the resources to deal with bugs in both the pNFS code and the NFSv2/v3 code at the same time. They would like the ability to ignore orthogonal upstream patches to get the features they want. I've seen no detailed risk analysis, so I can't confirm that there is significant additional risk to including the XDR patches with the pNFS wave going in 2.6.38.
Practically speaking, RH can safely ignore the NLM changes if they go upstream now, since there ought to be no intersection between pNFS and the NLM changes. To make the XDR changes ignorable, you could postpone the final two patches in that series until after pNFS is upstream, and there should be few if any merge conflicts with the existing pNFS waves. But I think those two patches were the reason we wanted to do this change now: we don't want to introduce any more uses of the old XDR API.
What we have been trying to do is to keep all of our efforts focused on upstream
kernel testing and pulling back aggressively. Staying focused on upstream (and
aggressively pulling that into fedora) is easy, it will of course get
increasingly less practical to pull that back into any long life vendor distro.
At some point, the amount of change requires a full, multi-week regression
(correctness, performance micro benchmarks & application testing). Not to
mention testing against the various vendors' NAS devices.
It is certainly quite reasonable to argue that the pNFS changes alone would
require a full regression, so we may as well pull in all of this at once if we
need to do it anyway.
Since people feel strongly supportive of this change set, I think we may as well
pull it in.
It will be great to get a sense of how others are going to test this (and
other!) changes in a comprehensive way. My concern is still that we are changing
a lot of things all at once - this change set changing the already stable bits &
the pNFS changes touching lots as well. Just a lot to digest all at once :)
Thanks!
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
