Disable NFS version 2
Subsystems (2)
PATCH 1/1 Disable NFS version 2
This patch disables the NFS version 2 module from being compile by default.
--- fs/nfs/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/Kconfig +2 -2
@@ -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"
Signature · 1 line
1.8.1.4
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?
Quoted 33 lines · Steve Dickson
This patch disables the NFS version 2 module from being compile by default.
Signed-off-by Steve Dickson <[email protected]>---
fs/nfs/Kconfig| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)fs/nfs/Kconfig +0
-0@@ -32,12 +32,12 @@ config NFS_FSconfig
NFS_V2
tristate "NFS client support for NFS version 2" depends onNFS_FSfs/nfs/Kconfig +1
-1- default y + default nhelp
This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client.fs/nfs/Kconfig +1
-1- If unsure, say Y. + If unsure, say n.config
NFS_V3
tristate "NFS client support for NFS version 3"Signature · 6 lines
1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
Hey,
Quoted 7 lines · Chuck Lever
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...
Quoted 3 lines
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...
Quoted 3 lines
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...
Quoted 3 lines
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.
Quoted 38 lines · Steve Dickson
Quoted 34 lines
This patch disables the NFS version 2 module from being compile by default.
Signed-off-by Steve Dickson <[email protected]>---
fs/nfs/Kconfig| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)fs/nfs/Kconfig +0
-0@@ -32,12 +32,12 @@ config NFS_FSconfig
NFS_V2
tristate "NFS client support for NFS version 2" depends onNFS_FSfs/nfs/Kconfig +1
-1- default y + default nhelp
This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client.fs/nfs/Kconfig +1
-1- If unsure, say Y. + If unsure, say n.config
NFS_V3
tristate "NFS client support for NFS version 3"Signature · 6 lines
1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Steve-
Quoted 7 lines · Steve Dickson
Hey,
Quoted 4 lines · Chuck Lever
Hi-
I'm not opposed to this change, but we should have some public discussion about it first.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 3 lines
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?
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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/Kconfigthe 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.
Quoted 46 lines
Thanks for the cycles!
steved.
Quoted 33 lines · Steve Dickson
Quoted 30 lines
This patch disables the NFS version 2 module from being compile by default.
Signed-off-by Steve Dickson <[email protected]>---
fs/nfs/Kconfig| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)fs/nfs/Kconfig +0
-0@@ -32,12 +32,12 @@ config NFS_FSconfig
NFS_V2
tristate "NFS client support for NFS version 2" depends onNFS_FSfs/nfs/Kconfig +1
-1- default y + default nhelp
This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client.fs/nfs/Kconfig +1
-1- If unsure, say Y. + If unsure, say n.config
NFS_V3
tristate "NFS client support for NFS version 3"Signature · 1 line
1.8.1.4Quoted 5 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
Quoted 34 lines · Chuck Lever
Hi Steve-
Quoted 12 lines · Steve Dickson
Hey,
Quoted 9 lines · Chuck Lever
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...?
Quoted 6 lines
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.
Quoted 7 lines
Quoted 4 lines
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...
Quoted 8 lines
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.
Quoted 11 lines
Is it a security
problem? Who are the stakeholders?Quoted 6 lines
Quoted 2 lines
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.
Quoted 44 lines · J. Bruce Fields
Quoted 34 lines · Chuck Lever
Hi Steve-
Quoted 12 lines · Steve Dickson
Hey,
Quoted 9 lines · Chuck Lever
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...?
Quoted 6 lines
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.
Quoted 7 lines
Quoted 4 lines
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...
Quoted 8 lines
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?
Quoted 6 lines
I think the most recent motivation was the bug discussed here:
http://thread.gmane.org/gmane.linux.nfs/52589/focus=52626which 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.
Quoted 28 lines
Quoted 4 lines
Is it a security
problem? Who are the stakeholders?Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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??)
Quoted 3 lines
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.
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
Quoted 19 lines · J. Bruce Fields
Quoted 2 lines · Chuck Lever
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??)
Quoted 3 lines
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?
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
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
Quoted 26 lines · Chuck Lever
Hi Steve-
Quoted 7 lines · Steve Dickson
Hey,
Quoted 4 lines · Chuck Lever
Hi-
I'm not opposed to this change, but we should have some public discussion about it first.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 3 lines
Quoted 3 lines
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?)
Quoted 7 lines
Quoted 2 lines
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...
Quoted 2 lines
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...
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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...
Quoted 3 lines
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.
Quoted 4 lines
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?
Quoted 11 lines
Quoted 5 lines
Quoted 3 lines
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/Kconfigthe only place I need to turn it off?
arch/*/configs/*_defconfigThese were not updated when the NFS client was modularized, so they currently do not list an explicit
CONFIG_NFS_V2setting. IIUC that means changingKconfigought to be enough.
Cool...
steved.
Quoted 48 lines
Quoted 47 lines
Thanks for the cycles!
steved.
Quoted 33 lines · Steve Dickson
Quoted 30 lines
This patch disables the NFS version 2 module from being compile by default.
Signed-off-by Steve Dickson <[email protected]>---
fs/nfs/Kconfig| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)fs/nfs/Kconfig +0
-0@@ -32,12 +32,12 @@ config NFS_FSconfig
NFS_V2
tristate "NFS client support for NFS version 2" depends onNFS_FSfs/nfs/Kconfig +1
-1- default y + default nhelp
This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client.fs/nfs/Kconfig +1
-1- If unsure, say Y. + If unsure, say n.config
NFS_V3
tristate "NFS client support for NFS version 3"Signature · 1 line
1.8.1.4Quoted 5 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 29 lines · Steve Dickson
Quoted 26 lines · Chuck Lever
Hi Steve-
Quoted 7 lines · Steve Dickson
Hey,
Quoted 4 lines · Chuck Lever
Hi-
I'm not opposed to this change, but we should have some public discussion about it first.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 3 lines
Quoted 3 lines
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?)
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
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!
Quoted 8 lines
Quoted 3 lines
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...
Quoted 1 line
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 4 lines
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?
Quoted 8 lines
Yes, the mount command no longer negotiates down to v2. The -o v2 mount option still works.
Quoted 4 lines
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.
Quoted 67 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Finally, if we go with something like this change, does this patch also need to update the default configurations shipped with the kernel?
Quoted 8 lines
Quoted 2 lines
What "default configurations shipped with the kernel"? Isn't
fs/nfs/Kconfigthe only place I need to turn it off?
arch/*/configs/*_defconfigThese were not updated when the NFS client was modularized, so they currently do not list an explicit
CONFIG_NFS_V2setting. IIUC that means changingKconfigought to be enough.Cool...
steved.
Quoted 43 lines
Quoted 43 lines
Thanks for the cycles!
steved.
Quoted 38 lines · Steve Dickson
Quoted 34 lines
This patch disables the NFS version 2 module from being compile by default.
Signed-off-by Steve Dickson <[email protected]>---
fs/nfs/Kconfig| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)fs/nfs/Kconfig +0
-0@@ -32,12 +32,12 @@ config NFS_FSconfig
NFS_V2
tristate "NFS client support for NFS version 2" depends onNFS_FSfs/nfs/Kconfig +1
-1- default y + default nhelp
This option enables support for version 2 of the NFS protocol (RFC 1094) in the kernel's NFS client.fs/nfs/Kconfig +1
-1- If unsure, say Y. + If unsure, say n.config
NFS_V3
tristate "NFS client support for NFS version 3"Signature · 6 lines
1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.htmlQuoted 5 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com