On Jul 5, 2013, at 3:52 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Fri, Jul 05, 2013 at 10:59:59AM -0400, Chuck Lever wrote: >> Hi Steve- >> >> On Jul 5, 2013, at 7:31 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >>> Hey, >>> >>> On 03/07/13 09:19, Chuck Lever wrote: >>>> Hi- >>>> >>>> I'm not opposed to this change, but we should have some public >>>> discussion about it first. >>>> >>>> If we make this proposed upstream change, NFSv2 will be built far >>>> less often and will be a magnet for code rot. It might make more >>>> sense to simply leave the "compile this out" choice up to >>>> distributions...? >>> Code rot is a possibility for any code where default is 'n' so that >>> means we should never use it? If that is the case, we should have >>> swap over NFS and Label NFS on be default on by default so those >>> bits don't rote... My point being, I don't think code rot should be >>> a reason for us to maintain code people should not be using in the >>> first place... >> >> In the case at hand, code rot isn't much of a risk if the point is to >> remove a feature. But that point wasn't stated anywhere. >> >>>> I'd like to reduce the risk of the kernel carrying around code >>>> that no-one uses or compiles. If we truly want this off by default >>>> everywhere, shouldn't we just remove it? (Is that the eventual >>>> goal?) >>> I would think so. Turn it off and see who screams.. Then get the >>> clue-bat out for for those people that do scream... ;-) They can >>> always turn it back on... >> >> If deprecation is the long-term goal, we ought to have a stated plan >> that we all agree on. We're talking about removing a feature of Linux >> NFS that has been a mainstay for, literally, decades. Make some >> noise, let people chime in, and publish a plan so folks know what to >> expect. >> >> We should also document publicly why we think NFSv2 support should go >> away. Is it a significant maintenance burden? > > I think the most recent motivation was the bug discussed here: > > http://thread.gmane.org/gmane.linux.nfs/52589/focus=52626 > > which itself was given as evidence of some continuing maintenance > burden. That seems more like "Who will rid me of this turbulent priest". Or... practically speaking we are not really maintaining it. If anything that e-mail is evidence that NFSv2 should be removed because it is unmaintained, not because it is a burden. By removing NFSv2 in the client and not in the server, we defy the de facto requirement that the Linux server and client capabilities should remain close. Is there no consequence to having NFSv2 support in the Linux server and not in the client? How are you going to test NFSv2 support in the server, for example? I still think having a deprecation plan is a good idea. > >> Is it a security >> problem? Who are the stakeholders? >> >>>> Should the server also disable NFSv2 support by default? If not, >>>> then why is the client special in this regard? >>> We have to start somewhere... It was just easier to start with the >>> client. If Bruce is interested in dropping v2 support on the server, >>> I will be more than willing to looking into that... Actually it >>> might just be a nfs-utils only thing... >> >> It feels like we should have a plan for both the server and client. > > That discussion brought out of the woodwork a couple people still > claiming to depend on v2. They seemed to only care about the server > side (because they had some old (non-linux) clients that were still > using v2 for some reason). > There could be other cases of people depending on an application tied to > an obsolete client OS that still expect to be able to upgrade their > server. > I may be wrong, but I'd expect the same situation (needing an obsolete > server to be able to access some data) to be rarer. (One possible > exception I noticed is vesta: http://www.vestasys.org/--source-code > management system with built-in v2-only server. Wonder if it's still > alive??) > > Anyway I'm inclined to treat dropping server protocol support by the > same standard as we'd treat dropping kernel ABI: as in, it's only OK if > we don't expect anyone to notice. Do we know how commercial storage vendors are going to approach this? I expect that, as soon as the numbers are small enough, they will tell their NFSv2-dependent customers to pound sand. In other words, is it worth discussing global NFSv2 deprecation at an NFS community event? Seems like this is an important interoperability issue. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
