Hello On 12/16/2010 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. Cool... > 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. As of the 2.6.32 kernel we have been pulling in all the NFS (both client and server) changes from every major release. Meaning at this point the RHEL6.1 NFS code will be bug for bug compatible with the NFS code in the 2.6.37 mainline kernel. So no, we have not been reject many patches. The reason we have been pulling in the entire releases is because when the pNFS bits are ready, we just want to pull them in and not have a backport from hell, basically forking from upstream. Think of what has changed between the 2.6.32 and 2.6.37 kernels. Backports like that are basically forks, IMHO... Keeping with this theory, when 2.6.38 is release we would pull in the pNFS bits but also all the changes to parts of the code that doesn't seem to be broken. The problem for us is RHEL6 has been released so the days of me pushing in hundreds and hundreds of patches that change parts of the code that, again, are not broken are gone. We simply do not have the resources to QA that amount of changes. Finally, history has shown, backporting large chucks of code out of a major release basically turns into a fork as well, which will not help us or more importantly not help this community. > 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? I don't know... We could look into something like this, but from an upstream perspective, would it be worth it? Does it make sense? Again I don't know Trond, it will not be the end of the world if RHEL6 does not have pNFS support... Again I think it would help the community by move the technology forward sooner verse later, but if it does not work out... so be it.. We will just move the support to RHEL 7 and move on... Heck that would make my life much easier (which I'm *always* a fan of ;-) ) and we always have Fedora... Its just when I heard, in this week's pNFS meeting, how close we were of having some meaningful pNFS bits (i.e. wave2), we decided to make this highly unusual (some call it shameful) request of asking to minimize changes until the pNFS bits stabilize... Thank you for even considering it... steved. -- 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
