| Message ID | 1353339810-19126-1-git-send-email-steved@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
T24gTW9uLCAyMDEyLTExLTE5IGF0IDEwOjQzIC0wNTAwLCBTdGV2ZSBEaWNrc29uIHdyb3RlOg0K PiBUaGlzIHBhdGNoIHdpbGwgY29udmVydCAtbyB2NC4xLCB2ZXJzPTQuMSBvciBuZnN2ZXJzPTQu MSBpbnRvDQo+IHRoZSBjb3JyZXNwb25kaW5nICJ2NCxtaW5vcnZlcnNpb249MSIsICJ2ZXJzPTQs bWlub3J2ZXJzaW9uPTEiDQo+IG9yICJuZnN2ZXJzPTQsbWlub3J2ZXJzaW9uPTEiIG9wdGlvbnMu DQo+IA0KDQpOQUNLLg0KDQpJZiB5b3UgYXJlIGdvaW5nIHRvIGRvIHRoaXMsIHRoZW4gcGxlYXNl IGRvIGl0IG9ubHkgZm9yIGtlcm5lbHMgdGhhdA0KZG9uJ3Qgc3VwcG9ydCB0aGUgInZlcnM9NC4x IiBzeW50YXguIGkuZS4gYW55dGhpbmcgb2xkZXIgdGhhbiBMaW51eC0zLjQuDQoNCldlIHdhbnQg dG8gZ2V0IHJpZCBvZiBtaW5vcnZlcnNpb249eCwgbm90IHBlcnBldHVhdGUgaXQuLi4NCg0KLS0g DQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHAN ClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- 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 19/11/12 10:54, Myklebust, Trond wrote: > On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: >> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into >> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" >> or "nfsvers=4,minorversion=1" options. >> > > NACK. > > If you are going to do this, then please do it only for kernels that > don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. This is the intention... > > We want to get rid of minorversion=x, not perpetuate it... > Understood... But that is not option in some worlds... ;-) steved. -- 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
T24gTW9uLCAyMDEyLTExLTE5IGF0IDEwOjU4IC0wNTAwLCBTdGV2ZSBEaWNrc29uIHdyb3RlOg0K PiANCj4gT24gMTkvMTEvMTIgMTA6NTQsIE15a2xlYnVzdCwgVHJvbmQgd3JvdGU6DQo+ID4gT24g TW9uLCAyMDEyLTExLTE5IGF0IDEwOjQzIC0wNTAwLCBTdGV2ZSBEaWNrc29uIHdyb3RlOg0KPiA+ PiBUaGlzIHBhdGNoIHdpbGwgY29udmVydCAtbyB2NC4xLCB2ZXJzPTQuMSBvciBuZnN2ZXJzPTQu MSBpbnRvDQo+ID4+IHRoZSBjb3JyZXNwb25kaW5nICJ2NCxtaW5vcnZlcnNpb249MSIsICJ2ZXJz PTQsbWlub3J2ZXJzaW9uPTEiDQo+ID4+IG9yICJuZnN2ZXJzPTQsbWlub3J2ZXJzaW9uPTEiIG9w dGlvbnMuDQo+ID4+DQo+ID4gDQo+ID4gTkFDSy4NCj4gPiANCj4gPiBJZiB5b3UgYXJlIGdvaW5n IHRvIGRvIHRoaXMsIHRoZW4gcGxlYXNlIGRvIGl0IG9ubHkgZm9yIGtlcm5lbHMgdGhhdA0KPiA+ IGRvbid0IHN1cHBvcnQgdGhlICJ2ZXJzPTQuMSIgc3ludGF4LiBpLmUuIGFueXRoaW5nIG9sZGVy IHRoYW4gTGludXgtMy40Lg0KPiBUaGlzIGlzIHRoZSBpbnRlbnRpb24uLi4gDQo+IA0KPiA+IA0K PiA+IFdlIHdhbnQgdG8gZ2V0IHJpZCBvZiBtaW5vcnZlcnNpb249eCwgbm90IHBlcnBldHVhdGUg aXQuLi4NCj4gPiANCj4gVW5kZXJzdG9vZC4uLiBCdXQgdGhhdCBpcyBub3Qgb3B0aW9uIGluIHNv bWUgd29ybGRzLi4uIDstKSANCg0KU3VyZSBpdCBpcy4gVGhlIG1vdW50IHByb2dyYW0gY2FuIGNv bnRpbnVlIHRvIHBhcnNlIG1pbm9ydmVyc2lvbj0gYWZ0ZXINCml0IGlzIGdvbmUgZnJvbSB0aGUg a2VybmVsIGFuZCBjb252ZXJ0IGl0IGludG8gdGhlIHZlcnM9NC54IHN5bnRheC4NCg0KLS0gDQpU cm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRy b25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- 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 19/11/12 11:02, Myklebust, Trond wrote: > On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote: >> >> On 19/11/12 10:54, Myklebust, Trond wrote: >>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: >>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into >>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" >>>> or "nfsvers=4,minorversion=1" options. >>>> >>> >>> NACK. >>> >>> If you are going to do this, then please do it only for kernels that >>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. >> This is the intention... >> >>> >>> We want to get rid of minorversion=x, not perpetuate it... >>> >> Understood... But that is not option in some worlds... ;-) > > Sure it is. The mount program can continue to parse minorversion= after > it is gone from the kernel and convert it into the vers=4.x syntax. > Basically what I'm doing now, with the exception of not adding the minorversion=1 options... BTW, there is a bug in the -o v4.1 current logic... mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given to the kernel which does not seem right... I would assume just a "v4.1,.." should be pumped down.. steved. -- 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 Mon, 2012-11-19 at 11:14 -0500, Steve Dickson wrote: > > On 19/11/12 11:02, Myklebust, Trond wrote: > > On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote: > >> > >> On 19/11/12 10:54, Myklebust, Trond wrote: > >>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: > >>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into > >>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" > >>>> or "nfsvers=4,minorversion=1" options. > >>>> > >>> > >>> NACK. > >>> > >>> If you are going to do this, then please do it only for kernels that > >>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. > >> This is the intention... > >> > >>> > >>> We want to get rid of minorversion=x, not perpetuate it... > >>> > >> Understood... But that is not option in some worlds... ;-) > > > > Sure it is. The mount program can continue to parse minorversion= after > > it is gone from the kernel and convert it into the vers=4.x syntax. > > > Basically what I'm doing now, with the exception of not adding > the minorversion=1 options... > > BTW, there is a bug in the -o v4.1 current logic... > > mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given > to the kernel which does not seem right... I would assume just a "v4.1,.." > should be pumped down.. Yes. I remember seeing that in the Bakeathon tests... I agree that we just need the vers=4.1. The extra 'vers=4' isn't harmful in that the kernel won't interpret it as vers=4.0, but it would be nice to get rid of it. Essentially, the plan is that some time in the future we will want to have 'vers=4' be the 'auto-negotiate minor version' syntax, while vers=4.x will be the 'use minor version x' syntax. Of course, auto-negotiation should be driven by the 'mount' program, which will be using the 'vers=4.x' syntax in the mount system call, for various values of 'x', until it achieves success. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Nov 19, 2012, at 11:24 AM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Mon, 2012-11-19 at 11:14 -0500, Steve Dickson wrote: >> >> On 19/11/12 11:02, Myklebust, Trond wrote: >>> On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote: >>>> >>>> On 19/11/12 10:54, Myklebust, Trond wrote: >>>>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: >>>>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into >>>>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" >>>>>> or "nfsvers=4,minorversion=1" options. >>>>>> >>>>> >>>>> NACK. >>>>> >>>>> If you are going to do this, then please do it only for kernels that >>>>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. >>>> This is the intention... >>>> >>>>> >>>>> We want to get rid of minorversion=x, not perpetuate it... >>>>> >>>> Understood... But that is not option in some worlds... ;-) >>> >>> Sure it is. The mount program can continue to parse minorversion= after >>> it is gone from the kernel and convert it into the vers=4.x syntax. >>> >> Basically what I'm doing now, with the exception of not adding >> the minorversion=1 options... >> >> BTW, there is a bug in the -o v4.1 current logic... >> >> mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given >> to the kernel which does not seem right... I would assume just a "v4.1,.." >> should be pumped down.. > > Yes. I remember seeing that in the Bakeathon tests... I agree that we > just need the vers=4.1. The extra 'vers=4' isn't harmful in that the > kernel won't interpret it as vers=4.0, but it would be nice to get rid > of it. > > Essentially, the plan is that some time in the future we will want to > have 'vers=4' be the 'auto-negotiate minor version' syntax, while > vers=4.x will be the 'use minor version x' syntax. > Of course, auto-negotiation should be driven by the 'mount' program, > which will be using the 'vers=4.x' syntax in the mount system call, for > various values of 'x', until it achieves success. Interesting. I assume you want "mount.nfs" to do this to allow some kind of auto-negotiation policy to be specified (say, via the mount command configuration file). As a design precursor, can you speculate on how the mount command would go about negotiating the minor version? mount.nfs cannot use protocol versions advertised by rpcbind, for instance, and neither can a simple NULL request identify which minor versions are available on the server.
On Nov 19, 2012, at 10:43 AM, Steve Dickson <steved@redhat.com> wrote: > This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into > the corresponding "v4,minorversion=1", "vers=4,minorversion=1" > or "nfsvers=4,minorversion=1" options. I had a couple of thoughts about this. As Trond points out, mount.nfs really should not use option "minorversion=" here, except on kernels that do not support "vers=4.x". That will add complexity, certainly. In addition, I think we can expect the need for support for "v4.2" and "v4.0" (perhaps) in the near future, and then subsequently "v4.3" and so on. Since that is close at hand, we should consider the need to add those as we design this. Perhaps instead of editing the mount option string directly in nfs_nfs_version(), you might add a "*minorversion" argument to nfs_nfs_version() function and let its callers finish the work, just as is done with "*version" today. That might also make it easier to add the logic that changes behavior based on kernel version. > > Signed-off-by: Steve Dickson <steved@redhat.com> > --- > utils/mount/network.c | 18 ++++++++++++++++-- > utils/mount/nfs.man | 13 +++++++++++++ > 2 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/utils/mount/network.c b/utils/mount/network.c > index e7bd522..36aa03b 100644 > --- a/utils/mount/network.c > +++ b/utils/mount/network.c > @@ -94,6 +94,7 @@ static const char *nfs_version_opttbl[] = { > "v2", > "v3", > "v4", > + "v4.1", > "vers", > "nfsvers", > NULL, > @@ -1244,11 +1245,20 @@ nfs_nfs_version(struct mount_options *options, unsigned long *version) > case 2: /* v4 */ > *version = 4; > return 1; > - case 3: /* vers */ > + case 3: /* v4.1 */ > + *version = 4; > + po_remove_all(options, "v4.1"); > + po_append(options, "v4,minorversion=1"); > + return 1; > + case 4: /* vers */ > switch (po_get_numeric(options, "vers", &tmp)) { > case PO_FOUND: > if (tmp >= 2 && tmp <= 4) { > *version = tmp; > + if (strcmp(po_get(options, "vers"), "4.1") == 0) { > + po_remove_all(options, "vers"); > + po_append(options, "vers=4,minorversion=1"); > + } > return 1; > } > return 0; > @@ -1261,11 +1271,15 @@ nfs_nfs_version(struct mount_options *options, unsigned long *version) > progname); > return 0; > } > - case 4: /* nfsvers */ > + case 5: /* nfsvers */ > switch (po_get_numeric(options, "nfsvers", &tmp)) { > case PO_FOUND: > if (tmp >= 2 && tmp <= 4) { > *version = tmp; > + if (strcmp(po_get(options, "nfsvers"), "4.1") == 0) { > + po_remove_all(options, "nfsvers"); > + po_append(options, "nfsvers=4,minorversion=1"); > + } > return 1; > } > return 0; > diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man > index c15de98..8d1bb56 100644 > --- a/utils/mount/nfs.man > +++ b/utils/mount/nfs.man > @@ -762,6 +762,19 @@ by 'nolock'/'lock' mount option. > Use these options, along with the options in the first subsection above, > for NFS version 4 and newer. > .TP 1.5i > +.BI minorversion= n > +Specifies the protocol minor version number. > +NFSv4 introduces "minor versioning," where NFS protocol enhancements can > +be introduced without bumping the NFS protocol version number. > +.IP > +The minor version can also be be specified using the > +.B vers= > +option. > +For example, specifying > +.B vers=4.1 > +is the same as specifying > +.BR vers=4,minorversion=1 . > +.TP 1.5i > .BI proto= netid > The > .I netid > -- > 1.7.11.7 > > -- > 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
T24gTW9uLCAyMDEyLTExLTE5IGF0IDEzOjExIC0wNTAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g T24gTm92IDE5LCAyMDEyLCBhdCAxMToyNCBBTSwgIk15a2xlYnVzdCwgVHJvbmQiIDxUcm9uZC5N eWtsZWJ1c3RAbmV0YXBwLmNvbT4gd3JvdGU6DQo+IA0KPiA+IE9uIE1vbiwgMjAxMi0xMS0xOSBh dCAxMToxNCAtMDUwMCwgU3RldmUgRGlja3NvbiB3cm90ZToNCj4gPj4gDQo+ID4+IE9uIDE5LzEx LzEyIDExOjAyLCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+Pj4gT24gTW9uLCAyMDEyLTEx LTE5IGF0IDEwOjU4IC0wNTAwLCBTdGV2ZSBEaWNrc29uIHdyb3RlOg0KPiA+Pj4+IA0KPiA+Pj4+ IE9uIDE5LzExLzEyIDEwOjU0LCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+Pj4+PiBPbiBN b24sIDIwMTItMTEtMTkgYXQgMTA6NDMgLTA1MDAsIFN0ZXZlIERpY2tzb24gd3JvdGU6DQo+ID4+ Pj4+PiBUaGlzIHBhdGNoIHdpbGwgY29udmVydCAtbyB2NC4xLCB2ZXJzPTQuMSBvciBuZnN2ZXJz PTQuMSBpbnRvDQo+ID4+Pj4+PiB0aGUgY29ycmVzcG9uZGluZyAidjQsbWlub3J2ZXJzaW9uPTEi LCAidmVycz00LG1pbm9ydmVyc2lvbj0xIg0KPiA+Pj4+Pj4gb3IgIm5mc3ZlcnM9NCxtaW5vcnZl cnNpb249MSIgb3B0aW9ucy4NCj4gPj4+Pj4+IA0KPiA+Pj4+PiANCj4gPj4+Pj4gTkFDSy4NCj4g Pj4+Pj4gDQo+ID4+Pj4+IElmIHlvdSBhcmUgZ29pbmcgdG8gZG8gdGhpcywgdGhlbiBwbGVhc2Ug ZG8gaXQgb25seSBmb3Iga2VybmVscyB0aGF0DQo+ID4+Pj4+IGRvbid0IHN1cHBvcnQgdGhlICJ2 ZXJzPTQuMSIgc3ludGF4LiBpLmUuIGFueXRoaW5nIG9sZGVyIHRoYW4gTGludXgtMy40Lg0KPiA+ Pj4+IFRoaXMgaXMgdGhlIGludGVudGlvbi4uLiANCj4gPj4+PiANCj4gPj4+Pj4gDQo+ID4+Pj4+ IFdlIHdhbnQgdG8gZ2V0IHJpZCBvZiBtaW5vcnZlcnNpb249eCwgbm90IHBlcnBldHVhdGUgaXQu Li4NCj4gPj4+Pj4gDQo+ID4+Pj4gVW5kZXJzdG9vZC4uLiBCdXQgdGhhdCBpcyBub3Qgb3B0aW9u IGluIHNvbWUgd29ybGRzLi4uIDstKSANCj4gPj4+IA0KPiA+Pj4gU3VyZSBpdCBpcy4gVGhlIG1v dW50IHByb2dyYW0gY2FuIGNvbnRpbnVlIHRvIHBhcnNlIG1pbm9ydmVyc2lvbj0gYWZ0ZXINCj4g Pj4+IGl0IGlzIGdvbmUgZnJvbSB0aGUga2VybmVsIGFuZCBjb252ZXJ0IGl0IGludG8gdGhlIHZl cnM9NC54IHN5bnRheC4NCj4gPj4+IA0KPiA+PiBCYXNpY2FsbHkgd2hhdCBJJ20gZG9pbmcgbm93 LCB3aXRoIHRoZSBleGNlcHRpb24gb2Ygbm90IGFkZGluZw0KPiA+PiB0aGUgbWlub3J2ZXJzaW9u PTEgb3B0aW9ucy4uLiANCj4gPj4gDQo+ID4+IEJUVywgdGhlcmUgaXMgYSBidWcgaW4gdGhlIC1v IHY0LjEgY3VycmVudCBsb2dpYy4uLiANCj4gPj4gDQo+ID4+IG1vdW50IC1vIHY0LjEgcHJvZHVj ZXMgYm90aCAidjQuMSx2ZXJzPTQsLi4uIiBpbiB0aGUgc3RyaW5nIHRoYXQgZ2l2ZW4NCj4gPj4g dG8gdGhlIGtlcm5lbCB3aGljaCBkb2VzIG5vdCBzZWVtIHJpZ2h0Li4uIEkgd291bGQgYXNzdW1l IGp1c3QgYSAidjQuMSwuLiINCj4gPj4gc2hvdWxkIGJlIHB1bXBlZCBkb3duLi4gDQo+ID4gDQo+ ID4gWWVzLiBJIHJlbWVtYmVyIHNlZWluZyB0aGF0IGluIHRoZSBCYWtlYXRob24gdGVzdHMuLi4g SSBhZ3JlZSB0aGF0IHdlDQo+ID4ganVzdCBuZWVkIHRoZSB2ZXJzPTQuMS4gVGhlIGV4dHJhICd2 ZXJzPTQnIGlzbid0IGhhcm1mdWwgaW4gdGhhdCB0aGUNCj4gPiBrZXJuZWwgd29uJ3QgaW50ZXJw cmV0IGl0IGFzIHZlcnM9NC4wLCBidXQgaXQgd291bGQgYmUgbmljZSB0byBnZXQgcmlkDQo+ID4g b2YgaXQuDQo+ID4gDQo+ID4gRXNzZW50aWFsbHksIHRoZSBwbGFuIGlzIHRoYXQgc29tZSB0aW1l IGluIHRoZSBmdXR1cmUgd2Ugd2lsbCB3YW50IHRvDQo+ID4gaGF2ZSAndmVycz00JyBiZSB0aGUg J2F1dG8tbmVnb3RpYXRlIG1pbm9yIHZlcnNpb24nIHN5bnRheCwgd2hpbGUNCj4gPiB2ZXJzPTQu eCB3aWxsIGJlIHRoZSAndXNlIG1pbm9yIHZlcnNpb24geCcgc3ludGF4Lg0KPiA+IE9mIGNvdXJz ZSwgYXV0by1uZWdvdGlhdGlvbiBzaG91bGQgYmUgZHJpdmVuIGJ5IHRoZSAnbW91bnQnIHByb2dy YW0sDQo+ID4gd2hpY2ggd2lsbCBiZSB1c2luZyB0aGUgJ3ZlcnM9NC54JyBzeW50YXggaW4gdGhl IG1vdW50IHN5c3RlbSBjYWxsLCBmb3INCj4gPiB2YXJpb3VzIHZhbHVlcyBvZiAneCcsIHVudGls IGl0IGFjaGlldmVzIHN1Y2Nlc3MuDQo+IA0KPiBJbnRlcmVzdGluZy4gIEkgYXNzdW1lIHlvdSB3 YW50ICJtb3VudC5uZnMiIHRvIGRvIHRoaXMgdG8gYWxsb3cgc29tZSBraW5kIG9mIGF1dG8tbmVn b3RpYXRpb24gcG9saWN5IHRvIGJlIHNwZWNpZmllZCAoc2F5LCB2aWEgdGhlIG1vdW50IGNvbW1h bmQgY29uZmlndXJhdGlvbiBmaWxlKS4NCg0KUmlnaHQuIEknZCBsaWtlIHRvIGJlIGFibGUgdG8g c2V0IERlZmF1bHR2ZXJzPTQuMSBpbiAvZXRjL25mc21vdW50LmNvbmYNCmFuZCBoYXZlIGl0IHdv cmsuDQoNCj4gQXMgYSBkZXNpZ24gcHJlY3Vyc29yLCBjYW4geW91IHNwZWN1bGF0ZSBvbiBob3cg dGhlIG1vdW50IGNvbW1hbmQgd291bGQgZ28gYWJvdXQgbmVnb3RpYXRpbmcgdGhlIG1pbm9yIHZl cnNpb24/ICBtb3VudC5uZnMgY2Fubm90IHVzZSBwcm90b2NvbCB2ZXJzaW9ucyBhZHZlcnRpc2Vk IGJ5IHJwY2JpbmQsIGZvciBpbnN0YW5jZSwgYW5kIG5laXRoZXIgY2FuIGEgc2ltcGxlIE5VTEwg cmVxdWVzdCBpZGVudGlmeSB3aGljaCBtaW5vciB2ZXJzaW9ucyBhcmUgYXZhaWxhYmxlIG9uIHRo ZSBzZXJ2ZXIuDQoNCk5vdGUgdGhhdCB0aGUgbW91bnQgY29tbWFuZCBzaG91bGQgaW4gYW55IGNh c2Ugbm90IGJlIHJlbHlpbmcgb24gcnBjYmluZA0KdG8gZGVjaWRlIHdoZXRoZXIgb3Igbm90IHRo ZSBzZXJ2ZXIgc3VwcG9ydHMgTkZTdjQuDQoNCkFzIGZvciBtaW5vciB2ZXJzaW9uIG5lZ290aWF0 aW9uLCBSRkMzNTMwIGFscmVhZHkgdGVsbHMgeW91IGhvdyB0byBkbw0KdGhpczogdGhlIGNsaWVu dCBoYXMgdG8gc3RhcnQgd2l0aCB0aGUgaGlnaGVzdCB2ZXJzaW9uIHRoYXQgaXQgc3VwcG9ydHMs DQphbmQgdGhlbiB3YWxrIHRoYXQgbnVtYmVyIGRvd24gdW50aWwgdGhlIHNlcnZlciBzdG9wcyBy ZXBseWluZyB3aXRoDQpORlM0RVJSX01JTk9SX1ZFUlNfTUlTTUFUQ0guDQoNCk5vdGUgdGhhdCBp ZiB5b3Ugd2FudCB0byBkbyB0aGlzIGluIHVzZXJsYW5kIGJlZm9yZSBjYWxsaW5nIHRoZSBtb3Vu dA0Kc3lzY2FsbCwgdGhlbiB0aGUgc3BlYyBkb2VzIGFsbG93IHlvdSB0byAicGluZyIgdGhlIE5G U3Y0IHNlcnZlciB3aXRoIGFuDQplbXB0eSBDT01QT1VORC4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1 c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVz dEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K -- 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 Nov 19, 2012, at 1:29 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Mon, 2012-11-19 at 13:11 -0500, Chuck Lever wrote: >> On Nov 19, 2012, at 11:24 AM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: >> >>> On Mon, 2012-11-19 at 11:14 -0500, Steve Dickson wrote: >>>> >>>> On 19/11/12 11:02, Myklebust, Trond wrote: >>>>> On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote: >>>>>> >>>>>> On 19/11/12 10:54, Myklebust, Trond wrote: >>>>>>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: >>>>>>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into >>>>>>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" >>>>>>>> or "nfsvers=4,minorversion=1" options. >>>>>>>> >>>>>>> >>>>>>> NACK. >>>>>>> >>>>>>> If you are going to do this, then please do it only for kernels that >>>>>>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. >>>>>> This is the intention... >>>>>> >>>>>>> >>>>>>> We want to get rid of minorversion=x, not perpetuate it... >>>>>>> >>>>>> Understood... But that is not option in some worlds... ;-) >>>>> >>>>> Sure it is. The mount program can continue to parse minorversion= after >>>>> it is gone from the kernel and convert it into the vers=4.x syntax. >>>>> >>>> Basically what I'm doing now, with the exception of not adding >>>> the minorversion=1 options... >>>> >>>> BTW, there is a bug in the -o v4.1 current logic... >>>> >>>> mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given >>>> to the kernel which does not seem right... I would assume just a "v4.1,.." >>>> should be pumped down.. >>> >>> Yes. I remember seeing that in the Bakeathon tests... I agree that we >>> just need the vers=4.1. The extra 'vers=4' isn't harmful in that the >>> kernel won't interpret it as vers=4.0, but it would be nice to get rid >>> of it. >>> >>> Essentially, the plan is that some time in the future we will want to >>> have 'vers=4' be the 'auto-negotiate minor version' syntax, while >>> vers=4.x will be the 'use minor version x' syntax. >>> Of course, auto-negotiation should be driven by the 'mount' program, >>> which will be using the 'vers=4.x' syntax in the mount system call, for >>> various values of 'x', until it achieves success. >> >> Interesting. I assume you want "mount.nfs" to do this to allow some kind of auto-negotiation policy to be specified (say, via the mount command configuration file). > > Right. I'd like to be able to set Defaultvers=4.1 in /etc/nfsmount.conf > and have it work. > >> As a design precursor, can you speculate on how the mount command would go about negotiating the minor version? mount.nfs cannot use protocol versions advertised by rpcbind, for instance, and neither can a simple NULL request identify which minor versions are available on the server. > > Note that the mount command should in any case not be relying on rpcbind > to decide whether or not the server supports NFSv4. > > As for minor version negotiation, RFC3530 already tells you how to do > this: the client has to start with the highest version that it supports, > and then walk that number down until the server stops replying with > NFS4ERR_MINOR_VERS_MISMATCH. > > Note that if you want to do this in userland before calling the mount > syscall, then the spec does allow you to "ping" the NFSv4 server with an > empty COMPOUND. I see: not an NFSv4 NULL, but an NFSv4 COMPOUND that has no operations. That carries a compound header, which would have the minor version number in it.
On Mon, 2012-11-19 at 13:39 -0500, Chuck Lever wrote: > On Nov 19, 2012, at 1:29 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > > > On Mon, 2012-11-19 at 13:11 -0500, Chuck Lever wrote: > >> On Nov 19, 2012, at 11:24 AM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > >> > >>> On Mon, 2012-11-19 at 11:14 -0500, Steve Dickson wrote: > >>>> > >>>> On 19/11/12 11:02, Myklebust, Trond wrote: > >>>>> On Mon, 2012-11-19 at 10:58 -0500, Steve Dickson wrote: > >>>>>> > >>>>>> On 19/11/12 10:54, Myklebust, Trond wrote: > >>>>>>> On Mon, 2012-11-19 at 10:43 -0500, Steve Dickson wrote: > >>>>>>>> This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into > >>>>>>>> the corresponding "v4,minorversion=1", "vers=4,minorversion=1" > >>>>>>>> or "nfsvers=4,minorversion=1" options. > >>>>>>>> > >>>>>>> > >>>>>>> NACK. > >>>>>>> > >>>>>>> If you are going to do this, then please do it only for kernels that > >>>>>>> don't support the "vers=4.1" syntax. i.e. anything older than Linux-3.4. > >>>>>> This is the intention... > >>>>>> > >>>>>>> > >>>>>>> We want to get rid of minorversion=x, not perpetuate it... > >>>>>>> > >>>>>> Understood... But that is not option in some worlds... ;-) > >>>>> > >>>>> Sure it is. The mount program can continue to parse minorversion= after > >>>>> it is gone from the kernel and convert it into the vers=4.x syntax. > >>>>> > >>>> Basically what I'm doing now, with the exception of not adding > >>>> the minorversion=1 options... > >>>> > >>>> BTW, there is a bug in the -o v4.1 current logic... > >>>> > >>>> mount -o v4.1 produces both "v4.1,vers=4,..." in the string that given > >>>> to the kernel which does not seem right... I would assume just a "v4.1,.." > >>>> should be pumped down.. > >>> > >>> Yes. I remember seeing that in the Bakeathon tests... I agree that we > >>> just need the vers=4.1. The extra 'vers=4' isn't harmful in that the > >>> kernel won't interpret it as vers=4.0, but it would be nice to get rid > >>> of it. > >>> > >>> Essentially, the plan is that some time in the future we will want to > >>> have 'vers=4' be the 'auto-negotiate minor version' syntax, while > >>> vers=4.x will be the 'use minor version x' syntax. > >>> Of course, auto-negotiation should be driven by the 'mount' program, > >>> which will be using the 'vers=4.x' syntax in the mount system call, for > >>> various values of 'x', until it achieves success. > >> > >> Interesting. I assume you want "mount.nfs" to do this to allow some kind of auto-negotiation policy to be specified (say, via the mount command configuration file). > > > > Right. I'd like to be able to set Defaultvers=4.1 in /etc/nfsmount.conf > > and have it work. > > > >> As a design precursor, can you speculate on how the mount command would go about negotiating the minor version? mount.nfs cannot use protocol versions advertised by rpcbind, for instance, and neither can a simple NULL request identify which minor versions are available on the server. > > > > Note that the mount command should in any case not be relying on rpcbind > > to decide whether or not the server supports NFSv4. > > > > As for minor version negotiation, RFC3530 already tells you how to do > > this: the client has to start with the highest version that it supports, > > and then walk that number down until the server stops replying with > > NFS4ERR_MINOR_VERS_MISMATCH. > > > > Note that if you want to do this in userland before calling the mount > > syscall, then the spec does allow you to "ping" the NFSv4 server with an > > empty COMPOUND. > > I see: not an NFSv4 NULL, but an NFSv4 COMPOUND that has no operations. That carries a compound header, which would have the minor version number in it. Right. Section 16.2.4 of RFC5661 would appear to allow the server to return the following errors in the case of an empty COMPOUND: NFS4_OK, NFS4ERR_DELAY, NFS4ERR_MINOR_VERS_MISMATCH and NFS4ERR_SERVERFAULT. The other errors shouldn't apply at all to a zero-op compound (NFS4ERR_BADXDR, NFS4ERR_TOO_MANY_OPS, NFS4ERR_REP_TOO_BIG_TO_CACHE), or should only apply if you have a non-empty optional tag argument (NFS4ERR_BADCHAR, NFS4ERR_INVAL, NFS4ERR_REP_TOO_BIG, NFS4ERR_REQ_TOO_BIG). -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Mon, Nov 19, 2012 at 07:04:10PM +0000, Myklebust, Trond wrote: > On Mon, 2012-11-19 at 13:39 -0500, Chuck Lever wrote: > > On Nov 19, 2012, at 1:29 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > > > As for minor version negotiation, RFC3530 already tells you how to do > > > this: the client has to start with the highest version that it supports, > > > and then walk that number down until the server stops replying with > > > NFS4ERR_MINOR_VERS_MISMATCH. > > > > > > Note that if you want to do this in userland before calling the mount > > > syscall, then the spec does allow you to "ping" the NFSv4 server with an > > > empty COMPOUND. > > > > I see: not an NFSv4 NULL, but an NFSv4 COMPOUND that has no operations. That carries a compound header, which would have the minor version number in it. > > Right. Section 16.2.4 of RFC5661 would appear to allow the server to > return the following errors in the case of an empty COMPOUND: NFS4_OK, > NFS4ERR_DELAY, NFS4ERR_MINOR_VERS_MISMATCH and NFS4ERR_SERVERFAULT. > > The other errors shouldn't apply at all to a zero-op compound > (NFS4ERR_BADXDR, NFS4ERR_TOO_MANY_OPS, NFS4ERR_REP_TOO_BIG_TO_CACHE), or > should only apply if you have a non-empty optional tag argument > (NFS4ERR_BADCHAR, NFS4ERR_INVAL, NFS4ERR_REP_TOO_BIG, > NFS4ERR_REQ_TOO_BIG). And, I just wanted to check because I hadn't thought about this before: the Linux server does appear to handle 0-length compounds correctly. (And there's a 4.0 pynfs test, COMP1, which checks that a server will accept a zero-length compound, so anyone that's run pynfs should have noticed if there server doesn't.) --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 19/11/12 13:29, Myklebust, Trond wrote: > Note that the mount command should in any case not be relying on rpcbind > to decide whether or not the server supports NFSv4. Of course.... > > As for minor version negotiation, RFC3530 already tells you how to do > this: the client has to start with the highest version that it supports, > and then walk that number down until the server stops replying with > NFS4ERR_MINOR_VERS_MISMATCH. Perfect... I think we should do *all* v4 negotiation from the mount command... It's so much acceptable to replace mount.nfs binaries than kernels... > > Note that if you want to do this in userland before calling the mount > syscall, then the spec does allow you to "ping" the NFSv4 server with an > empty COMPOUND. The type of functionality will allow us to better deal with legacy servers, IMHO.. steved. -- 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 19/11/12 13:21, Chuck Lever wrote: > > As Trond points out, mount.nfs really should not use option "minorversion=" here, except on kernels that do not support "vers=4.x". That will add complexity, certainly. I agree... The patch I put out today was just an RFC... I just wanted to get the conversation started... > > In addition, I think we can expect the need for support for "v4.2" and "v4.0" (perhaps) in the near future, and then subsequently "v4.3" and so on. Since that is close at hand, we should consider the need to add those as we design this. Right, I thinking bring this type of negotiation back up to userland is the right thing to do... > > Perhaps instead of editing the mount option string directly in nfs_nfs_version(), you might add a "*minorversion" argument to nfs_nfs_version() function and let its callers finish the work, just as is done with "*version" today. That might also make it easier to add the logic that changes behavior based on kernel version. Let me digest this... I've noticed that in recent kernels that minorversion always seems to be set... steved. -- 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/utils/mount/network.c b/utils/mount/network.c index e7bd522..36aa03b 100644 --- a/utils/mount/network.c +++ b/utils/mount/network.c @@ -94,6 +94,7 @@ static const char *nfs_version_opttbl[] = { "v2", "v3", "v4", + "v4.1", "vers", "nfsvers", NULL, @@ -1244,11 +1245,20 @@ nfs_nfs_version(struct mount_options *options, unsigned long *version) case 2: /* v4 */ *version = 4; return 1; - case 3: /* vers */ + case 3: /* v4.1 */ + *version = 4; + po_remove_all(options, "v4.1"); + po_append(options, "v4,minorversion=1"); + return 1; + case 4: /* vers */ switch (po_get_numeric(options, "vers", &tmp)) { case PO_FOUND: if (tmp >= 2 && tmp <= 4) { *version = tmp; + if (strcmp(po_get(options, "vers"), "4.1") == 0) { + po_remove_all(options, "vers"); + po_append(options, "vers=4,minorversion=1"); + } return 1; } return 0; @@ -1261,11 +1271,15 @@ nfs_nfs_version(struct mount_options *options, unsigned long *version) progname); return 0; } - case 4: /* nfsvers */ + case 5: /* nfsvers */ switch (po_get_numeric(options, "nfsvers", &tmp)) { case PO_FOUND: if (tmp >= 2 && tmp <= 4) { *version = tmp; + if (strcmp(po_get(options, "nfsvers"), "4.1") == 0) { + po_remove_all(options, "nfsvers"); + po_append(options, "nfsvers=4,minorversion=1"); + } return 1; } return 0; diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man index c15de98..8d1bb56 100644 --- a/utils/mount/nfs.man +++ b/utils/mount/nfs.man @@ -762,6 +762,19 @@ by 'nolock'/'lock' mount option. Use these options, along with the options in the first subsection above, for NFS version 4 and newer. .TP 1.5i +.BI minorversion= n +Specifies the protocol minor version number. +NFSv4 introduces "minor versioning," where NFS protocol enhancements can +be introduced without bumping the NFS protocol version number. +.IP +The minor version can also be be specified using the +.B vers= +option. +For example, specifying +.B vers=4.1 +is the same as specifying +.BR vers=4,minorversion=1 . +.TP 1.5i .BI proto= netid The .I netid
This patch will convert -o v4.1, vers=4.1 or nfsvers=4.1 into the corresponding "v4,minorversion=1", "vers=4,minorversion=1" or "nfsvers=4,minorversion=1" options. Signed-off-by: Steve Dickson <steved@redhat.com> --- utils/mount/network.c | 18 ++++++++++++++++-- utils/mount/nfs.man | 13 +++++++++++++ 2 files changed, 29 insertions(+), 2 deletions(-)