| Message ID | 1372856675-5520-1-git-send-email-steved@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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...? 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?) Should the server also disable NFSv2 support by default? If not, then why is the client special in this regard? Finally, if we go with something like this change, does this patch also need to update the default configurations shipped with the kernel? On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@redhat.com> wrote: > This patch disables the NFS version 2 module from being compile by default. > > Signed-off-by: Steve Dickson <steved@redhat.com> > --- > fs/nfs/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig > index 13ca196..6831a01 100644 > --- a/fs/nfs/Kconfig > +++ b/fs/nfs/Kconfig > @@ -32,12 +32,12 @@ config NFS_FS > config NFS_V2 > tristate "NFS client support for NFS version 2" > depends on NFS_FS > - default y > + default n > help > This option enables support for version 2 of the NFS protocol > (RFC 1094) in the kernel's NFS client. > > - If unsure, say Y. > + If unsure, say n. > > config NFS_V3 > tristate "NFS client support for NFS version 3" > -- > 1.8.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
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... > 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... > > 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... > > Finally, if we go with something like this change, does this patch also need to > update the default configurations shipped with the kernel? What "default configurations shipped with the kernel"? Isn't fs/nfs/Kconfig the only place I need to turn it off? Thanks for the cycles! steved. > > > On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@redhat.com> wrote: > >> This patch disables the NFS version 2 module from being compile by default. >> >> Signed-off-by: Steve Dickson <steved@redhat.com> >> --- >> fs/nfs/Kconfig | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig >> index 13ca196..6831a01 100644 >> --- a/fs/nfs/Kconfig >> +++ b/fs/nfs/Kconfig >> @@ -32,12 +32,12 @@ config NFS_FS >> config NFS_V2 >> tristate "NFS client support for NFS version 2" >> depends on NFS_FS >> - default y >> + default n >> help >> This option enables support for version 2 of the NFS protocol >> (RFC 1094) in the kernel's NFS client. >> >> - If unsure, say Y. >> + If unsure, say n. >> >> config NFS_V3 >> tristate "NFS client support for NFS version 3" >> -- >> 1.8.1.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Steve- On Jul 5, 2013, at 7:31 AM, Steve Dickson <SteveD@redhat.com> 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? 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. You could remove NFSv2 support in nfs-utils on both sides, I would think. Didn't you already remove NFSv2 from the mount.nfs command's version negotiation? Deprecating a kernel feature also has a pathway through the staging tree, IIUC. Would that be appropriate for NFSv2? It may even be a requirement these days, but I'm not sure. >> Finally, if we go with something like this change, does this patch also need to >> update the default configurations shipped with the kernel? > What "default configurations shipped with the kernel"? Isn't fs/nfs/Kconfig the > only place I need to turn it off? arch/*/configs/*_defconfig These were not updated when the NFS client was modularized, so they currently do not list an explicit CONFIG_NFS_V2 setting. IIUC that means changing Kconfig ought to be enough. > Thanks for the cycles! > > steved. > >> >> >> On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@redhat.com> wrote: >> >>> This patch disables the NFS version 2 module from being compile by default. >>> >>> Signed-off-by: Steve Dickson <steved@redhat.com> >>> --- >>> fs/nfs/Kconfig | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig >>> index 13ca196..6831a01 100644 >>> --- a/fs/nfs/Kconfig >>> +++ b/fs/nfs/Kconfig >>> @@ -32,12 +32,12 @@ config NFS_FS >>> config NFS_V2 >>> tristate "NFS client support for NFS version 2" >>> depends on NFS_FS >>> - default y >>> + default n >>> help >>> This option enables support for version 2 of the NFS protocol >>> (RFC 1094) in the kernel's NFS client. >>> >>> - If unsure, say Y. >>> + If unsure, say n. >>> >>> config NFS_V3 >>> tristate "NFS client support for NFS version 3" >>> -- >>> 1.8.1.4 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
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@redhat.com> 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. > 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. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul 5, 2013, at 3:52 PM, J. Bruce Fields <bfields@fieldses.org> 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@redhat.com> 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.
On 05/07/13 10:59, Chuck Lever wrote: > Hi Steve- > > On Jul 5, 2013, at 7:31 AM, Steve Dickson <SteveD@redhat.com> 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. That was the purpose of this patch... to start the conversation... > > We should also document publicly why we think NFSv2 support should go away. Is it a < significant maintenance burden? Is it a security problem? Who are the stakeholders? Its mostly maintenances and limited testing resource. I would rather use cycles to fix/test v4... > >>> 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. I'm thinking we could do it separately... > > You could remove NFSv2 support in nfs-utils on both sides, I would think. Didn't you > already remove NFSv2 from the mount.nfs command's version negotiation? Yes, the mount command no longer negotiates down to v2. The -o v2 mount option still works. > > Deprecating a kernel feature also has a pathway through the staging tree, IIUC. > Would that be appropriate for NFSv2? It may even be a requirement these days, but > I'm not sure. Really? Anybody know what that pathway is? > >>> Finally, if we go with something like this change, does this patch also need to >>> update the default configurations shipped with the kernel? >> What "default configurations shipped with the kernel"? Isn't fs/nfs/Kconfig the >> only place I need to turn it off? > > arch/*/configs/*_defconfig > > These were not updated when the NFS client was modularized, so they currently do not > list an explicit CONFIG_NFS_V2 setting. IIUC that means changing Kconfig ought to be > enough. Cool... steved. > >> Thanks for the cycles! >> >> steved. >> >>> >>> >>> On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@redhat.com> wrote: >>> >>>> This patch disables the NFS version 2 module from being compile by default. >>>> >>>> Signed-off-by: Steve Dickson <steved@redhat.com> >>>> --- >>>> fs/nfs/Kconfig | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig >>>> index 13ca196..6831a01 100644 >>>> --- a/fs/nfs/Kconfig >>>> +++ b/fs/nfs/Kconfig >>>> @@ -32,12 +32,12 @@ config NFS_FS >>>> config NFS_V2 >>>> tristate "NFS client support for NFS version 2" >>>> depends on NFS_FS >>>> - default y >>>> + default n >>>> help >>>> This option enables support for version 2 of the NFS protocol >>>> (RFC 1094) in the kernel's NFS client. >>>> >>>> - If unsure, say Y. >>>> + If unsure, say n. >>>> >>>> config NFS_V3 >>>> tristate "NFS client support for NFS version 3" >>>> -- >>>> 1.8.1.4 >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul 8, 2013, at 8:53 AM, Steve Dickson <SteveD@redhat.com> wrote: > > > On 05/07/13 10:59, Chuck Lever wrote: >> Hi Steve- >> >> On Jul 5, 2013, at 7:31 AM, Steve Dickson <SteveD@redhat.com> 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. > That was the purpose of this patch... to start the conversation... It's good for Linux to take some leadership here. Thanks! > >> >> We should also document publicly why we think NFSv2 support should go away. Is it a > < significant maintenance burden? Is it a security problem? Who are the stakeholders? > Its mostly maintenances and limited testing resource. I would rather use cycles > to fix/test v4... > >> >>>> 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. > I'm thinking we could do it separately... I think we need to plan both, at least, whether we execute the plan on the server-side or not. We may find some dependencies between the server and client, or we may identify other requirements for deprecating support on either side. > >> >> You could remove NFSv2 support in nfs-utils on both sides, I would think. Didn't you >> already remove NFSv2 from the mount.nfs command's version negotiation? > Yes, the mount command no longer negotiates down to v2. The -o v2 mount > option still works. > >> >> Deprecating a kernel feature also has a pathway through the staging tree, IIUC. >> Would that be appropriate for NFSv2? It may even be a requirement these days, but >> I'm not sure. > Really? Anybody know what that pathway is? I'm asking now in a private thread. > >> >>>> Finally, if we go with something like this change, does this patch also need to >>>> update the default configurations shipped with the kernel? >>> What "default configurations shipped with the kernel"? Isn't fs/nfs/Kconfig the >>> only place I need to turn it off? >> >> arch/*/configs/*_defconfig >> >> These were not updated when the NFS client was modularized, so they currently do not >> list an explicit CONFIG_NFS_V2 setting. IIUC that means changing Kconfig ought to be >> enough. > Cool... > > steved. >> >>> Thanks for the cycles! >>> >>> steved. >>> >>>> >>>> >>>> On Jul 3, 2013, at 9:04 AM, Steve Dickson <steved@redhat.com> wrote: >>>> >>>>> This patch disables the NFS version 2 module from being compile by default. >>>>> >>>>> Signed-off-by: Steve Dickson <steved@redhat.com> >>>>> --- >>>>> fs/nfs/Kconfig | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig >>>>> index 13ca196..6831a01 100644 >>>>> --- a/fs/nfs/Kconfig >>>>> +++ b/fs/nfs/Kconfig >>>>> @@ -32,12 +32,12 @@ config NFS_FS >>>>> config NFS_V2 >>>>> tristate "NFS client support for NFS version 2" >>>>> depends on NFS_FS >>>>> - default y >>>>> + default n >>>>> help >>>>> This option enables support for version 2 of the NFS protocol >>>>> (RFC 1094) in the kernel's NFS client. >>>>> >>>>> - If unsure, say Y. >>>>> + If unsure, say n. >>>>> >>>>> config NFS_V3 >>>>> tristate "NFS client support for NFS version 3" >>>>> -- >>>>> 1.8.1.4 >>>>> >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul 5, 2013, at 3:52 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Fri, Jul 05, 2013 at 10:59:59AM -0400, Chuck Lever wrote: >> >> 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. I'm wondering why this requirement does not also apply to the client. I've heard the opinion expressed recently that we really should not deprecate a feature that still has users. It might be reasonable to bring this question up on lkml, specifically in the context of NFS version 2. For the sake of argument, what would induce us to keep NFSv2 in the client? Finding someone to maintain it?
T24gTW9uLCAyMDEzLTA3LTA4IGF0IDEwOjQ3IC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g T24gSnVsIDUsIDIwMTMsIGF0IDM6NTIgUE0sIEouIEJydWNlIEZpZWxkcyA8YmZpZWxkc0BmaWVs ZHNlcy5vcmc+IHdyb3RlOg0KPiANCj4gPiBPbiBGcmksIEp1bCAwNSwgMjAxMyBhdCAxMDo1OTo1 OUFNIC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4gPj4gDQo+ID4+IEl0IGZlZWxzIGxpa2Ug d2Ugc2hvdWxkIGhhdmUgYSBwbGFuIGZvciBib3RoIHRoZSBzZXJ2ZXIgYW5kIGNsaWVudC4NCj4g PiANCj4gPiBUaGF0IGRpc2N1c3Npb24gYnJvdWdodCBvdXQgb2YgdGhlIHdvb2R3b3JrIGEgY291 cGxlIHBlb3BsZSBzdGlsbA0KPiA+IGNsYWltaW5nIHRvIGRlcGVuZCBvbiB2Mi4gIFRoZXkgc2Vl bWVkIHRvIG9ubHkgY2FyZSBhYm91dCB0aGUgc2VydmVyDQo+ID4gc2lkZSAoYmVjYXVzZSB0aGV5 IGhhZCBzb21lIG9sZCAobm9uLWxpbnV4KSBjbGllbnRzIHRoYXQgd2VyZSBzdGlsbA0KPiA+IHVz aW5nIHYyIGZvciBzb21lIHJlYXNvbikuDQo+ID4gDQo+ID4gVGhlcmUgY291bGQgYmUgb3RoZXIg Y2FzZXMgb2YgcGVvcGxlIGRlcGVuZGluZyBvbiBhbiBhcHBsaWNhdGlvbiB0aWVkIHRvDQo+ID4g YW4gb2Jzb2xldGUgY2xpZW50IE9TIHRoYXQgc3RpbGwgZXhwZWN0IHRvIGJlIGFibGUgdG8gdXBn cmFkZSB0aGVpcg0KPiA+IHNlcnZlci4NCj4gPiANCj4gPiBJIG1heSBiZSB3cm9uZywgYnV0IEkn ZCBleHBlY3QgdGhlIHNhbWUgc2l0dWF0aW9uIChuZWVkaW5nIGFuIG9ic29sZXRlDQo+ID4gc2Vy dmVyIHRvIGJlIGFibGUgdG8gYWNjZXNzIHNvbWUgZGF0YSkgdG8gYmUgcmFyZXIuICAoT25lIHBv c3NpYmxlDQo+ID4gZXhjZXB0aW9uIEkgbm90aWNlZCBpcyB2ZXN0YTogaHR0cDovL3d3dy52ZXN0 YXN5cy5vcmcvLS1zb3VyY2UtY29kZQ0KPiA+IG1hbmFnZW1lbnQgc3lzdGVtIHdpdGggYnVpbHQt aW4gdjItb25seSBzZXJ2ZXIuICBXb25kZXIgaWYgaXQncyBzdGlsbA0KPiA+IGFsaXZlPz8pDQo+ ID4gDQo+ID4gQW55d2F5IEknbSBpbmNsaW5lZCB0byB0cmVhdCBkcm9wcGluZyBzZXJ2ZXIgcHJv dG9jb2wgc3VwcG9ydCBieSB0aGUNCj4gPiBzYW1lIHN0YW5kYXJkIGFzIHdlJ2QgdHJlYXQgZHJv cHBpbmcga2VybmVsIEFCSTogYXMgaW4sIGl0J3Mgb25seSBPSyBpZg0KPiA+IHdlIGRvbid0IGV4 cGVjdCBhbnlvbmUgdG8gbm90aWNlLg0KPiANCj4gSSdtIHdvbmRlcmluZyB3aHkgdGhpcyByZXF1 aXJlbWVudCBkb2VzIG5vdCBhbHNvIGFwcGx5IHRvIHRoZSBjbGllbnQuICBJJ3ZlIGhlYXJkIHRo ZSBvcGluaW9uIGV4cHJlc3NlZCByZWNlbnRseSB0aGF0IHdlIHJlYWxseSBzaG91bGQgbm90IGRl cHJlY2F0ZSBhIGZlYXR1cmUgdGhhdCBzdGlsbCBoYXMgdXNlcnMuDQo+IA0KPiBJdCBtaWdodCBi ZSByZWFzb25hYmxlIHRvIGJyaW5nIHRoaXMgcXVlc3Rpb24gdXAgb24gbGttbCwgc3BlY2lmaWNh bGx5IGluIHRoZSBjb250ZXh0IG9mIE5GUyB2ZXJzaW9uIDIuDQo+IA0KPiBGb3IgdGhlIHNha2Ug b2YgYXJndW1lbnQsIHdoYXQgd291bGQgaW5kdWNlIHVzIHRvIGtlZXAgTkZTdjIgaW4gdGhlIGNs aWVudD8gIEZpbmRpbmcgc29tZW9uZSB0byBtYWludGFpbiBpdD8NCj4gDQoNCkZpbmRpbmcgdXNl cnMuLi4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5l cg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig index 13ca196..6831a01 100644 --- a/fs/nfs/Kconfig +++ b/fs/nfs/Kconfig @@ -32,12 +32,12 @@ config NFS_FS config NFS_V2 tristate "NFS client support for NFS version 2" depends on NFS_FS - default y + default n help This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client. - If unsure, say Y. + If unsure, say n. config NFS_V3 tristate "NFS client support for NFS version 3"
This patch disables the NFS version 2 module from being compile by default. Signed-off-by: Steve Dickson <steved@redhat.com> --- fs/nfs/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)