I'm getting
# mount -tnfs -onfsvers=4 pip1:/exports /mnt/
(OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
I doubt they're related.)
Also:
[root@pip2 ~]# modprobe nfs4
[root@pip2 ~]# lsmod|grep nfs4
[root@pip2 ~]#
--b.
On Tue, 7 Aug 2012 22:36:12 +0000
"Myklebust, Trond" <[email protected]> wrote:
> On Tue, 2012-08-07 at 18:26 -0400, Jeff Layton wrote:
> > On Tue, 7 Aug 2012 21:23:34 +0000
> > "Myklebust, Trond" <[email protected]> wrote:
> >
> > > On Tue, 2012-08-07 at 16:25 -0400, J. Bruce Fields wrote:
> > > > On Tue, Aug 07, 2012 at 04:10:49PM -0400, Bryan Schumaker wrote:
> > > > > On 08/07/2012 03:57 PM, J. Bruce Fields wrote:
> > > > > > On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
> > > > > >> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
> > > > > >>> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
> > > > > >>>> On Sat, 4 Aug 2012 15:01:04 -0400
> > > > > >>>> "J. Bruce Fields" <[email protected]> wrote:
> > > > > >>>>
> > > > > >>>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> > > > > >>>>>> On Fri, 3 Aug 2012 20:08:19 -0400
> > > > > >>>>>> "J. Bruce Fields" <[email protected]> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> I'm getting
> > > > > >>>>>>>
> > > > > >>>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> > > > > >>>>>>>
> > > > > >>>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > > > > >>>>>>> I doubt they're related.)
> > > > > >>>>>>>
> > > > > >>>>>>> Also:
> > > > > >>>>>>>
> > > > > >>>>>>> [root@pip2 ~]# modprobe nfs4
> > > > > >>>>>>> [root@pip2 ~]# lsmod|grep nfs4
> > > > > >>>>>>> [root@pip2 ~]#
> > > > > >>>>>>>
> > > > > >>>>>>> --b.
> > > > > >>>>>>
> > > > > >>>>>> I hit the same problem...
> > > > > >>>>>>
> > > > > >>>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> > > > > >>>>>> Fedora).
> > > > > >>>>>
> > > > > >>>>> Oog, right.
> > > > > >>>>>
> > > > > >>>>> But, without testing--won't that make v4 mounts fail on older kernels?
> > > > > >>>>
> > > > > >>>> Actually, now that I look, this does not seem to break on older kernels
> > > > > >>>> as long as you use a syntax like:
> > > > > >>>>
> > > > > >>>> # mount -t nfs server:/export /mnt/point -o vers=4
> > > > > >>>>
> > > > > >>>> ...if, however you use a syntax like:
> > > > > >>>>
> > > > > >>>> # mount -t nfs4 server:/export /mnt/point
> > > > > >>>>
> > > > > >>>> ...then it fails without the above file in place. I guess the question
> > > > > >>>> we have to answer is: Do we want to continue to support the "-t nfs4"
> > > > > >>>> mount syntax?
> > > > > >>>
> > > > > >>> I think you're right that we want to deprecate it.
> > > > > >>>
> > > > > >>> Though this is a bit of a harsh way to do it--would have been nice to
> > > > > >>> have some transition period with a warning or something.
> > > > > >>
> > > > > >> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
> > > > > >
> > > > > > Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
> > > > > > modprobe configuration, and sure enough I get "No such device".
> > > > > >
> > > > > > Maybe you have some initscripts or something else that's loading the
> > > > > > nfs module for you before the mount?
> > > > >
> > > > > My nfs-common daemon script loads sunrpc, nfs
> > > >
> > > > Yep, that's why you're not seeing it.
> > > >
> > > > > and nfsd but not nfs2, nfs3 or nfs4.
> > > > >
> > > > > Could we rename the module to avoid the alias name collision? Something like this (untested) maybe?
> > > >
> > > > I don't think that will help.
> > >
> > > It should if we also add back in
> > >
> > > struct file_system_type nfs4_fs_type = {
> > > .owner = THIS_MODULE,
> > > .name = "nfs4",
> > > .mount = nfs_fs_mount,
> > > .kill_sb = nfs_kill_super,
> > > .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
> > > };
> > >
> > > and then add that to register_nfs_fs()/unregister_nfs_fs(). As far as I
> > > can see, that will trigger all the right incantations in
> > > nfs_validate_mount_data() to mount an NFSv4 filesystem.
> > >
> >
> > So, move the nfs4 fstype definition back into nfs.ko? That would
> > ensure that you could still do a "-t nfs4" mount with that modprobe
> > alias in place.
>
> No. I mean to add a separate nfs4_fstype definition in nfs.ko, and
> register it so that the VFS recognises the 'nfs4' filesystem name.
>
> > I think Bryan is correct though. We'll also need to rename nfs4.ko or
> > you won't ever be able to call request_module for it in order to plug
> > it in if you have that module alias in place.
>
> You did note my use of the word "also" above?
>
> > Does this mean that we plan to support the "-t nfs4" mount syntax in
> > perpetuity?
>
> No, but I also agree with Bruce's point that we shouldn't pull the plug
> without some prior notice. We should at least keep an entry in
> Documentation/feature-removal-schedule.txt for a few kernel revisions.
>
Ok, I follow you now...
Fair warning is reasonable, perhaps we should shoot for removing
support in 3.9 or 3.10?
I think we'll also need to consider retiring the nfs4_fs_type
altogether, or at least make them all show up as "nfs"
in /proc/self/mounts. Otherwise remounts could be problematic...
--
Jeff Layton <[email protected]>
T24gV2VkLCAyMDEyLTA4LTA4IGF0IDEwOjQyIC0wNDAwLCBCcnlhbiBTY2h1bWFrZXIgd3JvdGU6
DQo+IFNvIHlvdSdyZSBzdWdnZXN0aW5nIHNvbWV0aGluZyBsaWtlIHRoaXM/ICBJIGNhbiBzcGxp
dCBpdCBpbnRvIHR3byBwYXRjaGVzIGZvciB0aGUgZmluYWwgc3VibWlzc2lvbiwgb25lIHRvIHJl
bmFtZSB0aGUgbW9kdWxlcyBhbmQgb25lIHRvIG1vdmUgdGhlIG5mczRfZnNfdHlwZSBiYWNrIHRv
IG5mcy5rby4NCg0KT25lIHBhdGNoIHNob3VsZCBzdWZmaWNlLCBzaW5jZSB5b3UgY2FuJ3Qgc3Bs
aXQgdGhpcyB1cCBpbnRvIHNvbWV0aGluZw0KdGhhdCBmaXhlcyBib3RoIGlzc3Vlcy4NCg0KVGhl
biBtYXliZSB3ZSBjYW4gYWRkIGEgc2VwYXJhdGUgcGF0Y2ggd2l0aCBhIE1PRFVMRV9BTElBUygi
bmZzNCIpIHNvDQp0aGF0IGRpc3Ryb3MgY2FuIHN0YXJ0IHJlbW92aW5nIHRoZSAvZXRjL21vZHBy
b2JlLmNvbmYgYWxpYXMgZW50cmllcy4NCg0KPiBkaWZmIC0tZ2l0IGEvZnMvbmZzL01ha2VmaWxl
IGIvZnMvbmZzL01ha2VmaWxlDQo+IGluZGV4IDhiZjNhM2YuLmI3ZGI2MDggMTAwNjQ0DQo+IC0t
LSBhL2ZzL25mcy9NYWtlZmlsZQ0KPiArKysgYi9mcy9uZnMvTWFrZWZpbGUNCj4gQEAgLTEyLDE5
ICsxMiwxOSBAQCBuZnMtJChDT05GSUdfUk9PVF9ORlMpCSs9IG5mc3Jvb3Qubw0KPiAgbmZzLSQo
Q09ORklHX1NZU0NUTCkJKz0gc3lzY3RsLm8NCj4gIG5mcy0kKENPTkZJR19ORlNfRlNDQUNIRSkg
Kz0gZnNjYWNoZS5vIGZzY2FjaGUtaW5kZXgubw0KPiAgDQo+IC1vYmotJChDT05GSUdfTkZTX1Yy
KSArPSBuZnMyLm8NCj4gLW5mczIteSA6PSBuZnMyc3VwZXIubyBwcm9jLm8gbmZzMnhkci5vDQo+
ICtvYmotJChDT05GSUdfTkZTX1YyKSArPSBuZnN2Mi5vDQo+ICtuZnN2Mi15IDo9IG5mczJzdXBl
ci5vIHByb2MubyBuZnMyeGRyLm8NCj4gIA0KPiAtb2JqLSQoQ09ORklHX05GU19WMykgKz0gbmZz
My5vDQo+IC1uZnMzLXkgOj0gbmZzM3N1cGVyLm8gbmZzM2NsaWVudC5vIG5mczNwcm9jLm8gbmZz
M3hkci5vDQo+IC1uZnMzLSQoQ09ORklHX05GU19WM19BQ0wpICs9IG5mczNhY2wubw0KPiArb2Jq
LSQoQ09ORklHX05GU19WMykgKz0gbmZzdjMubw0KPiArbmZzdjMteSA6PSBuZnMzc3VwZXIubyBu
ZnMzY2xpZW50Lm8gbmZzM3Byb2MubyBuZnMzeGRyLm8NCj4gK25mc3YzLSQoQ09ORklHX05GU19W
M19BQ0wpICs9IG5mczNhY2wubw0KPiAgDQo+IC1vYmotJChDT05GSUdfTkZTX1Y0KSArPSBuZnM0
Lm8NCj4gLW5mczQteSA6PSBuZnM0cHJvYy5vIG5mczR4ZHIubyBuZnM0c3RhdGUubyBuZnM0cmVu
ZXdkLm8gbmZzNHN1cGVyLm8gbmZzNGZpbGUubyBcDQo+ICtvYmotJChDT05GSUdfTkZTX1Y0KSAr
PSBuZnN2NC5vDQo+ICtuZnN2NC15IDo9IG5mczRwcm9jLm8gbmZzNHhkci5vIG5mczRzdGF0ZS5v
IG5mczRyZW5ld2QubyBuZnM0c3VwZXIubyBuZnM0ZmlsZS5vIFwNCj4gIAkgIGRlbGVnYXRpb24u
byBpZG1hcC5vIGNhbGxiYWNrLm8gY2FsbGJhY2tfeGRyLm8gY2FsbGJhY2tfcHJvYy5vIFwNCj4g
IAkgIG5mczRuYW1lc3BhY2UubyBuZnM0Z2V0cm9vdC5vIG5mczRjbGllbnQubw0KPiAtbmZzNC0k
KENPTkZJR19TWVNDVEwpCSs9IG5mczRzeXNjdGwubw0KPiAtbmZzNC0kKENPTkZJR19ORlNfVjRf
MSkJKz0gcG5mcy5vIHBuZnNfZGV2Lm8NCj4gK25mc3Y0LSQoQ09ORklHX1NZU0NUTCkJKz0gbmZz
NHN5c2N0bC5vDQo+ICtuZnN2NC0kKENPTkZJR19ORlNfVjRfMSkJKz0gcG5mcy5vIHBuZnNfZGV2
Lm8NCj4gIA0KPiAgb2JqLSQoQ09ORklHX1BORlNfRklMRV9MQVlPVVQpICs9IG5mc19sYXlvdXRf
bmZzdjQxX2ZpbGVzLm8NCj4gIG5mc19sYXlvdXRfbmZzdjQxX2ZpbGVzLXkgOj0gbmZzNGZpbGVs
YXlvdXQubyBuZnM0ZmlsZWxheW91dGRldi5vDQo+IGRpZmYgLS1naXQgYS9mcy9uZnMvY2xpZW50
LmMgYi9mcy9uZnMvY2xpZW50LmMNCj4gaW5kZXggOWZjMGQ5ZC4uOTk2OTQ0NCAxMDA2NDQNCj4g
LS0tIGEvZnMvbmZzL2NsaWVudC5jDQo+ICsrKyBiL2ZzL25mcy9jbGllbnQuYw0KPiBAQCAtMTA1
LDcgKzEwNSw3IEBAIHN0cnVjdCBuZnNfc3VidmVyc2lvbiAqZ2V0X25mc192ZXJzaW9uKHVuc2ln
bmVkIGludCB2ZXJzaW9uKQ0KPiAgDQo+ICAJaWYgKElTX0VSUihuZnMpKSB7DQo+ICAJCW11dGV4
X2xvY2soJm5mc192ZXJzaW9uX211dGV4KTsNCj4gLQkJcmVxdWVzdF9tb2R1bGUoIm5mcyVkIiwg
dmVyc2lvbik7DQo+ICsJCXJlcXVlc3RfbW9kdWxlKCJuZnN2JWQiLCB2ZXJzaW9uKTsNCj4gIAkJ
bmZzID0gZmluZF9uZnNfdmVyc2lvbih2ZXJzaW9uKTsNCj4gIAkJbXV0ZXhfdW5sb2NrKCZuZnNf
dmVyc2lvbl9tdXRleCk7DQo+ICAJfQ0KPiBkaWZmIC0tZ2l0IGEvZnMvbmZzL25mczRfZnMuaCBi
L2ZzL25mcy9uZnM0X2ZzLmgNCj4gaW5kZXggMTljMWE1Ni4uNDNmNDk3MSAxMDA2NDQNCj4gLS0t
IGEvZnMvbmZzL25mczRfZnMuaA0KPiArKysgYi9mcy9uZnMvbmZzNF9mcy5oDQo+IEBAIC0yMDUs
NiArMjA1LDkgQEAgZXh0ZXJuIGNvbnN0IHN0cnVjdCBkZW50cnlfb3BlcmF0aW9ucyBuZnM0X2Rl
bnRyeV9vcGVyYXRpb25zOw0KPiAgaW50IG5mc19hdG9taWNfb3BlbihzdHJ1Y3QgaW5vZGUgKiwg
c3RydWN0IGRlbnRyeSAqLCBzdHJ1Y3QgZmlsZSAqLA0KPiAgDQo+ICsvKiBzdXBlci5jICovDQo+
ICtleHRlcm4gc3RydWN0IGZpbGVfc3lzdGVtX3R5cGUgbmZzNF9mc190eXBlOw0KPiArDQo+ICAv
KiBuZnM0bmFtZXNwYWNlLmMgKi8NCj4gIHJwY19hdXRoZmxhdm9yX3QgbmZzX2ZpbmRfYmVzdF9z
ZWMoc3RydWN0IG5mczRfc2VjaW5mb19mbGF2b3JzICopOw0KPiAgc3RydWN0IHJwY19jbG50ICpu
ZnM0X2NyZWF0ZV9zZWNfY2xpZW50KHN0cnVjdCBycGNfY2xudCAqLCBzdHJ1Y3QgaW5vZGUgKiwg
c3RydWN0IHFzdHIgKik7DQo+IGRpZmYgLS1naXQgYS9mcy9uZnMvbmZzNHN1cGVyLmMgYi9mcy9u
ZnMvbmZzNHN1cGVyLmMNCj4gaW5kZXggMTJhMzFhOS4uYmQ2MTIyMSAxMDA2NDQNCj4gLS0tIGEv
ZnMvbmZzL25mczRzdXBlci5jDQo+ICsrKyBiL2ZzL25mcy9uZnM0c3VwZXIuYw0KPiBAQCAtMjMs
MTQgKzIzLDYgQEAgc3RhdGljIHN0cnVjdCBkZW50cnkgKm5mczRfcmVmZXJyYWxfbW91bnQoc3Ry
dWN0IGZpbGVfc3lzdGVtX3R5cGUgKmZzX3R5cGUsDQo+ICBzdGF0aWMgc3RydWN0IGRlbnRyeSAq
bmZzNF9yZW1vdGVfcmVmZXJyYWxfbW91bnQoc3RydWN0IGZpbGVfc3lzdGVtX3R5cGUgKmZzX3R5
cGUsDQo+ICAJaW50IGZsYWdzLCBjb25zdCBjaGFyICpkZXZfbmFtZSwgdm9pZCAqcmF3X2RhdGEp
Ow0KPiAgDQo+IC1zdGF0aWMgc3RydWN0IGZpbGVfc3lzdGVtX3R5cGUgbmZzNF9mc190eXBlID0g
ew0KPiAtCS5vd25lcgkJPSBUSElTX01PRFVMRSwNCj4gLQkubmFtZQkJPSAibmZzNCIsDQo+IC0J
Lm1vdW50CQk9IG5mc19mc19tb3VudCwNCj4gLQkua2lsbF9zYgk9IG5mc19raWxsX3N1cGVyLA0K
PiAtCS5mc19mbGFncwk9IEZTX1JFTkFNRV9ET0VTX0RfTU9WRXxGU19SRVZBTF9ET1R8RlNfQklO
QVJZX01PVU5UREFUQSwNCj4gLX07DQo+IC0NCj4gIHN0YXRpYyBzdHJ1Y3QgZmlsZV9zeXN0ZW1f
dHlwZSBuZnM0X3JlbW90ZV9mc190eXBlID0gew0KPiAgCS5vd25lcgkJPSBUSElTX01PRFVMRSwN
Cj4gIAkubmFtZQkJPSAibmZzNCIsDQo+IEBAIC0zNDQsMTQgKzMzNiw4IEBAIHN0YXRpYyBpbnQg
X19pbml0IGluaXRfbmZzX3Y0KHZvaWQpDQo+ICAJaWYgKGVycikNCj4gIAkJZ290byBvdXQxOw0K
PiAgDQo+IC0JZXJyID0gcmVnaXN0ZXJfZmlsZXN5c3RlbSgmbmZzNF9mc190eXBlKTsNCj4gLQlp
ZiAoZXJyIDwgMCkNCj4gLQkJZ290byBvdXQyOw0KPiAtDQo+ICAJcmVnaXN0ZXJfbmZzX3ZlcnNp
b24oJm5mc192NCk7DQo+ICAJcmV0dXJuIDA7DQo+IC1vdXQyOg0KPiAtCW5mczRfdW5yZWdpc3Rl
cl9zeXNjdGwoKTsNCj4gIG91dDE6DQo+ICAJbmZzX2lkbWFwX3F1aXQoKTsNCj4gIG91dDoNCj4g
QEAgLTM2MSw3ICszNDcsNiBAQCBvdXQ6DQo+ICBzdGF0aWMgdm9pZCBfX2V4aXQgZXhpdF9uZnNf
djQodm9pZCkNCj4gIHsNCj4gIAl1bnJlZ2lzdGVyX25mc192ZXJzaW9uKCZuZnNfdjQpOw0KPiAt
CXVucmVnaXN0ZXJfZmlsZXN5c3RlbSgmbmZzNF9mc190eXBlKTsNCj4gIAluZnM0X3VucmVnaXN0
ZXJfc3lzY3RsKCk7DQo+ICAJbmZzX2lkbWFwX3F1aXQoKTsNCj4gIH0NCj4gZGlmZiAtLWdpdCBh
L2ZzL25mcy9zdXBlci5jIGIvZnMvbmZzL3N1cGVyLmMNCj4gaW5kZXggYWM2YTNjNS4uNDliMmRm
YSAxMDA2NDQNCj4gLS0tIGEvZnMvbmZzL3N1cGVyLmMNCj4gKysrIGIvZnMvbmZzL3N1cGVyLmMN
Cj4gQEAgLTMxOSw2ICszMTksMTUgQEAgRVhQT1JUX1NZTUJPTF9HUEwobmZzX3NvcHMpOw0KPiAg
c3RhdGljIHZvaWQgbmZzNF92YWxpZGF0ZV9tb3VudF9mbGFncyhzdHJ1Y3QgbmZzX3BhcnNlZF9t
b3VudF9kYXRhICopOw0KPiAgc3RhdGljIGludCBuZnM0X3ZhbGlkYXRlX21vdW50X2RhdGEodm9p
ZCAqb3B0aW9ucywNCj4gIAlzdHJ1Y3QgbmZzX3BhcnNlZF9tb3VudF9kYXRhICphcmdzLCBjb25z
dCBjaGFyICpkZXZfbmFtZSk7DQo+ICsNCj4gK3N0cnVjdCBmaWxlX3N5c3RlbV90eXBlIG5mczRf
ZnNfdHlwZSA9IHsNCj4gKwkub3duZXIJCT0gVEhJU19NT0RVTEUsDQo+ICsJLm5hbWUJCT0gIm5m
czQiLA0KPiArCS5tb3VudAkJPSBuZnNfZnNfbW91bnQsDQo+ICsJLmtpbGxfc2IJPSBuZnNfa2ls
bF9zdXBlciwNCj4gKwkuZnNfZmxhZ3MJPSBGU19SRU5BTUVfRE9FU19EX01PVkV8RlNfUkVWQUxf
RE9UfEZTX0JJTkFSWV9NT1VOVERBVEEsDQo+ICt9Ow0KPiArRVhQT1JUX1NZTUJPTF9HUEwobmZz
NF9mc190eXBlKTsNCj4gICNlbmRpZg0KPiAgDQo+ICBzdGF0aWMgc3RydWN0IHNocmlua2VyIGFj
bF9zaHJpbmtlciA9IHsNCj4gQEAgLTMyNiw2ICszMzUsMjcgQEAgc3RhdGljIHN0cnVjdCBzaHJp
bmtlciBhY2xfc2hyaW5rZXIgPSB7DQo+ICAJLnNlZWtzCQk9IERFRkFVTFRfU0VFS1MsDQo+ICB9
Ow0KPiAgDQo+ICsjaWYgSVNfRU5BQkxFRChDT05GSUdfTkZTX1Y0KQ0KPiArc3RhdGljIGludCBf
X2luaXQgcmVnaXN0ZXJfbmZzNF9mcyh2b2lkKQ0KPiArew0KPiArCXJldHVybiByZWdpc3Rlcl9m
aWxlc3lzdGVtKCZuZnM0X2ZzX3R5cGUpOw0KPiArfQ0KPiArDQo+ICtzdGF0aWMgdm9pZCB1bnJl
Z2lzdGVyX25mczRfZnModm9pZCkNCj4gK3sNCj4gKwl1bnJlZ2lzdGVyX2ZpbGVzeXN0ZW0oJm5m
czRfZnNfdHlwZSk7DQo+ICt9DQo+ICsjZWxzZQ0KPiArc3RhdGljIGludCBfX2luaXQgcmVnaXN0
ZXJfbmZzNF9mcyh2b2lkKQ0KPiArew0KPiArCXJldHVybiAwOw0KPiArfQ0KPiArDQo+ICtzdGF0
aWMgdm9pZCB1bnJlZ2lzdGVyX25mczRfZnModm9pZCkNCj4gK3sNCj4gK30NCj4gKyNlbmRpZiAv
KiBDT05GSUdfTkZTX1Y0ICovDQoNCldoeSBub3QgcHV0IHRoZXNlIGhlbHBlcnMgaW4gdGhlIHNh
bWUgc2VjdGlvbiBhcyB0aGUgZGVjbGFyYXRpb24gb2YNCm5mczRfZnNfdHlwZT8NCg0KPiArDQo+
ICAvKg0KPiAgICogUmVnaXN0ZXIgdGhlIE5GUyBmaWxlc3lzdGVtcw0KPiAgICovDQo+IEBAIC0z
MzcsMTIgKzM2NywxOCBAQCBpbnQgX19pbml0IHJlZ2lzdGVyX25mc19mcyh2b2lkKQ0KPiAgCWlm
IChyZXQgPCAwKQ0KPiAgCQlnb3RvIGVycm9yXzA7DQo+ICANCj4gLQlyZXQgPSBuZnNfcmVnaXN0
ZXJfc3lzY3RsKCk7DQo+ICsJcmV0ID0gcmVnaXN0ZXJfbmZzNF9mcygpOw0KPiAgCWlmIChyZXQg
PCAwKQ0KPiAgCQlnb3RvIGVycm9yXzE7DQo+ICsNCj4gKwlyZXQgPSBuZnNfcmVnaXN0ZXJfc3lz
Y3RsKCk7DQo+ICsJaWYgKHJldCA8IDApDQo+ICsJCWdvdG8gZXJyb3JfMjsNCj4gIAlyZWdpc3Rl
cl9zaHJpbmtlcigmYWNsX3Nocmlua2VyKTsNCj4gIAlyZXR1cm4gMDsNCj4gIA0KPiArZXJyb3Jf
MjoNCj4gKwl1bnJlZ2lzdGVyX25mczRfZnMoKTsNCj4gIGVycm9yXzE6DQo+ICAJdW5yZWdpc3Rl
cl9maWxlc3lzdGVtKCZuZnNfZnNfdHlwZSk7DQo+ICBlcnJvcl8wOg0KPiBAQCAtMzU2LDYgKzM5
Miw3IEBAIHZvaWQgX19leGl0IHVucmVnaXN0ZXJfbmZzX2ZzKHZvaWQpDQo+ICB7DQo+ICAJdW5y
ZWdpc3Rlcl9zaHJpbmtlcigmYWNsX3Nocmlua2VyKTsNCj4gIAluZnNfdW5yZWdpc3Rlcl9zeXNj
dGwoKTsNCj4gKwl1bnJlZ2lzdGVyX25mczRfZnMoKTsNCj4gIAl1bnJlZ2lzdGVyX2ZpbGVzeXN0
ZW0oJm5mc19mc190eXBlKTsNCj4gIH0NCj4gIA0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGlu
dXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFw
cC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
On 08/07/2012 05:23 PM, Myklebust, Trond wrote:
> On Tue, 2012-08-07 at 16:25 -0400, J. Bruce Fields wrote:
>> On Tue, Aug 07, 2012 at 04:10:49PM -0400, Bryan Schumaker wrote:
>>> On 08/07/2012 03:57 PM, J. Bruce Fields wrote:
>>>> On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
>>>>> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
>>>>>> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
>>>>>>> On Sat, 4 Aug 2012 15:01:04 -0400
>>>>>>> "J. Bruce Fields" <[email protected]> wrote:
>>>>>>>
>>>>>>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
>>>>>>>>> On Fri, 3 Aug 2012 20:08:19 -0400
>>>>>>>>> "J. Bruce Fields" <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> I'm getting
>>>>>>>>>>
>>>>>>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
>>>>>>>>>>
>>>>>>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
>>>>>>>>>> I doubt they're related.)
>>>>>>>>>>
>>>>>>>>>> Also:
>>>>>>>>>>
>>>>>>>>>> [root@pip2 ~]# modprobe nfs4
>>>>>>>>>> [root@pip2 ~]# lsmod|grep nfs4
>>>>>>>>>> [root@pip2 ~]#
>>>>>>>>>>
>>>>>>>>>> --b.
>>>>>>>>>
>>>>>>>>> I hit the same problem...
>>>>>>>>>
>>>>>>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
>>>>>>>>> Fedora).
>>>>>>>>
>>>>>>>> Oog, right.
>>>>>>>>
>>>>>>>> But, without testing--won't that make v4 mounts fail on older kernels?
>>>>>>>
>>>>>>> Actually, now that I look, this does not seem to break on older kernels
>>>>>>> as long as you use a syntax like:
>>>>>>>
>>>>>>> # mount -t nfs server:/export /mnt/point -o vers=4
>>>>>>>
>>>>>>> ...if, however you use a syntax like:
>>>>>>>
>>>>>>> # mount -t nfs4 server:/export /mnt/point
>>>>>>>
>>>>>>> ...then it fails without the above file in place. I guess the question
>>>>>>> we have to answer is: Do we want to continue to support the "-t nfs4"
>>>>>>> mount syntax?
>>>>>>
>>>>>> I think you're right that we want to deprecate it.
>>>>>>
>>>>>> Though this is a bit of a harsh way to do it--would have been nice to
>>>>>> have some transition period with a warning or something.
>>>>>
>>>>> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
>>>>
>>>> Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
>>>> modprobe configuration, and sure enough I get "No such device".
>>>>
>>>> Maybe you have some initscripts or something else that's loading the
>>>> nfs module for you before the mount?
>>>
>>> My nfs-common daemon script loads sunrpc, nfs
>>
>> Yep, that's why you're not seeing it.
>>
>>> and nfsd but not nfs2, nfs3 or nfs4.
>>>
>>> Could we rename the module to avoid the alias name collision? Something like this (untested) maybe?
>>
>> I don't think that will help.
>
> It should if we also add back in
>
> struct file_system_type nfs4_fs_type = {
> .owner = THIS_MODULE,
> .name = "nfs4",
> .mount = nfs_fs_mount,
> .kill_sb = nfs_kill_super,
> .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
> };
>
> and then add that to register_nfs_fs()/unregister_nfs_fs(). As far as I
> can see, that will trigger all the right incantations in
> nfs_validate_mount_data() to mount an NFSv4 filesystem.
So you're suggesting something like this? I can split it into two patches for the final submission, one to rename the modules and one to move the nfs4_fs_type back to nfs.ko.
diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
index 8bf3a3f..b7db608 100644
--- a/fs/nfs/Makefile
+++ b/fs/nfs/Makefile
@@ -12,19 +12,19 @@ nfs-$(CONFIG_ROOT_NFS) += nfsroot.o
nfs-$(CONFIG_SYSCTL) += sysctl.o
nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
-obj-$(CONFIG_NFS_V2) += nfs2.o
-nfs2-y := nfs2super.o proc.o nfs2xdr.o
+obj-$(CONFIG_NFS_V2) += nfsv2.o
+nfsv2-y := nfs2super.o proc.o nfs2xdr.o
-obj-$(CONFIG_NFS_V3) += nfs3.o
-nfs3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
-nfs3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
+obj-$(CONFIG_NFS_V3) += nfsv3.o
+nfsv3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
+nfsv3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
-obj-$(CONFIG_NFS_V4) += nfs4.o
-nfs4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
+obj-$(CONFIG_NFS_V4) += nfsv4.o
+nfsv4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
delegation.o idmap.o callback.o callback_xdr.o callback_proc.o \
nfs4namespace.o nfs4getroot.o nfs4client.o
-nfs4-$(CONFIG_SYSCTL) += nfs4sysctl.o
-nfs4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
+nfsv4-$(CONFIG_SYSCTL) += nfs4sysctl.o
+nfsv4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o
nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 9fc0d9d..9969444 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -105,7 +105,7 @@ struct nfs_subversion *get_nfs_version(unsigned int version)
if (IS_ERR(nfs)) {
mutex_lock(&nfs_version_mutex);
- request_module("nfs%d", version);
+ request_module("nfsv%d", version);
nfs = find_nfs_version(version);
mutex_unlock(&nfs_version_mutex);
}
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 19c1a56..43f4971 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -205,6 +205,9 @@ extern const struct dentry_operations nfs4_dentry_operations;
int nfs_atomic_open(struct inode *, struct dentry *, struct file *,
+/* super.c */
+extern struct file_system_type nfs4_fs_type;
+
/* nfs4namespace.c */
rpc_authflavor_t nfs_find_best_sec(struct nfs4_secinfo_flavors *);
struct rpc_clnt *nfs4_create_sec_client(struct rpc_clnt *, struct inode *, struct qstr *);
diff --git a/fs/nfs/nfs4super.c b/fs/nfs/nfs4super.c
index 12a31a9..bd61221 100644
--- a/fs/nfs/nfs4super.c
+++ b/fs/nfs/nfs4super.c
@@ -23,14 +23,6 @@ static struct dentry *nfs4_referral_mount(struct file_system_type *fs_type,
static struct dentry *nfs4_remote_referral_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *raw_data);
-static struct file_system_type nfs4_fs_type = {
- .owner = THIS_MODULE,
- .name = "nfs4",
- .mount = nfs_fs_mount,
- .kill_sb = nfs_kill_super,
- .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
-};
-
static struct file_system_type nfs4_remote_fs_type = {
.owner = THIS_MODULE,
.name = "nfs4",
@@ -344,14 +336,8 @@ static int __init init_nfs_v4(void)
if (err)
goto out1;
- err = register_filesystem(&nfs4_fs_type);
- if (err < 0)
- goto out2;
-
register_nfs_version(&nfs_v4);
return 0;
-out2:
- nfs4_unregister_sysctl();
out1:
nfs_idmap_quit();
out:
@@ -361,7 +347,6 @@ out:
static void __exit exit_nfs_v4(void)
{
unregister_nfs_version(&nfs_v4);
- unregister_filesystem(&nfs4_fs_type);
nfs4_unregister_sysctl();
nfs_idmap_quit();
}
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index ac6a3c5..49b2dfa 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -319,6 +319,15 @@ EXPORT_SYMBOL_GPL(nfs_sops);
static void nfs4_validate_mount_flags(struct nfs_parsed_mount_data *);
static int nfs4_validate_mount_data(void *options,
struct nfs_parsed_mount_data *args, const char *dev_name);
+
+struct file_system_type nfs4_fs_type = {
+ .owner = THIS_MODULE,
+ .name = "nfs4",
+ .mount = nfs_fs_mount,
+ .kill_sb = nfs_kill_super,
+ .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
+};
+EXPORT_SYMBOL_GPL(nfs4_fs_type);
#endif
static struct shrinker acl_shrinker = {
@@ -326,6 +335,27 @@ static struct shrinker acl_shrinker = {
.seeks = DEFAULT_SEEKS,
};
+#if IS_ENABLED(CONFIG_NFS_V4)
+static int __init register_nfs4_fs(void)
+{
+ return register_filesystem(&nfs4_fs_type);
+}
+
+static void unregister_nfs4_fs(void)
+{
+ unregister_filesystem(&nfs4_fs_type);
+}
+#else
+static int __init register_nfs4_fs(void)
+{
+ return 0;
+}
+
+static void unregister_nfs4_fs(void)
+{
+}
+#endif /* CONFIG_NFS_V4 */
+
/*
* Register the NFS filesystems
*/
@@ -337,12 +367,18 @@ int __init register_nfs_fs(void)
if (ret < 0)
goto error_0;
- ret = nfs_register_sysctl();
+ ret = register_nfs4_fs();
if (ret < 0)
goto error_1;
+
+ ret = nfs_register_sysctl();
+ if (ret < 0)
+ goto error_2;
register_shrinker(&acl_shrinker);
return 0;
+error_2:
+ unregister_nfs4_fs();
error_1:
unregister_filesystem(&nfs_fs_type);
error_0:
@@ -356,6 +392,7 @@ void __exit unregister_nfs_fs(void)
{
unregister_shrinker(&acl_shrinker);
nfs_unregister_sysctl();
+ unregister_nfs4_fs();
unregister_filesystem(&nfs_fs_type);
}
>
>>>
>>>
>>>
>>> diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
>>> index 8bf3a3f..b7db608 100644
>>> --- a/fs/nfs/Makefile
>>> +++ b/fs/nfs/Makefile
>>> @@ -12,19 +12,19 @@ nfs-$(CONFIG_ROOT_NFS) += nfsroot.o
>>> nfs-$(CONFIG_SYSCTL) += sysctl.o
>>> nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
>>>
>>> -obj-$(CONFIG_NFS_V2) += nfs2.o
>>> -nfs2-y := nfs2super.o proc.o nfs2xdr.o
>>> +obj-$(CONFIG_NFS_V2) += nfsv2.o
>>> +nfsv2-y := nfs2super.o proc.o nfs2xdr.o
>>>
>>> -obj-$(CONFIG_NFS_V3) += nfs3.o
>>> -nfs3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
>>> -nfs3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
>>> +obj-$(CONFIG_NFS_V3) += nfsv3.o
>>> +nfsv3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
>>> +nfsv3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
>>>
>>> -obj-$(CONFIG_NFS_V4) += nfs4.o
>>> -nfs4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
>>> +obj-$(CONFIG_NFS_V4) += nfsv4.o
>>> +nfsv4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
>>> delegation.o idmap.o callback.o callback_xdr.o callback_proc.o \
>>> nfs4namespace.o nfs4getroot.o nfs4client.o
>>> -nfs4-$(CONFIG_SYSCTL) += nfs4sysctl.o
>>> -nfs4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
>>> +nfsv4-$(CONFIG_SYSCTL) += nfs4sysctl.o
>>> +nfsv4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
>>>
>>> obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o
>>> nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o
>>> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
>>> index 9fc0d9d..9969444 100644
>>> --- a/fs/nfs/client.c
>>> +++ b/fs/nfs/client.c
>>> @@ -105,7 +105,7 @@ struct nfs_subversion *get_nfs_version(unsigned int version)
>>>
>>> if (IS_ERR(nfs)) {
>>> mutex_lock(&nfs_version_mutex);
>>> - request_module("nfs%d", version);
>>> + request_module("nfsv%d", version);
>>> nfs = find_nfs_version(version);
>>> mutex_unlock(&nfs_version_mutex);
>>> }
>>>
>>>
>>>>
>>>> --b.
>>>>
>>>
>> --
>> 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
>
On 08/07/2012 03:57 PM, J. Bruce Fields wrote:
> On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
>> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
>>> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
>>>> On Sat, 4 Aug 2012 15:01:04 -0400
>>>> "J. Bruce Fields" <[email protected]> wrote:
>>>>
>>>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
>>>>>> On Fri, 3 Aug 2012 20:08:19 -0400
>>>>>> "J. Bruce Fields" <[email protected]> wrote:
>>>>>>
>>>>>>> I'm getting
>>>>>>>
>>>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
>>>>>>>
>>>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
>>>>>>> I doubt they're related.)
>>>>>>>
>>>>>>> Also:
>>>>>>>
>>>>>>> [root@pip2 ~]# modprobe nfs4
>>>>>>> [root@pip2 ~]# lsmod|grep nfs4
>>>>>>> [root@pip2 ~]#
>>>>>>>
>>>>>>> --b.
>>>>>>
>>>>>> I hit the same problem...
>>>>>>
>>>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
>>>>>> Fedora).
>>>>>
>>>>> Oog, right.
>>>>>
>>>>> But, without testing--won't that make v4 mounts fail on older kernels?
>>>>
>>>> Actually, now that I look, this does not seem to break on older kernels
>>>> as long as you use a syntax like:
>>>>
>>>> # mount -t nfs server:/export /mnt/point -o vers=4
>>>>
>>>> ...if, however you use a syntax like:
>>>>
>>>> # mount -t nfs4 server:/export /mnt/point
>>>>
>>>> ...then it fails without the above file in place. I guess the question
>>>> we have to answer is: Do we want to continue to support the "-t nfs4"
>>>> mount syntax?
>>>
>>> I think you're right that we want to deprecate it.
>>>
>>> Though this is a bit of a harsh way to do it--would have been nice to
>>> have some transition period with a warning or something.
>>
>> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
>
> Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
> modprobe configuration, and sure enough I get "No such device".
>
> Maybe you have some initscripts or something else that's loading the
> nfs module for you before the mount?
My nfs-common daemon script loads sunrpc, nfs and nfsd but not nfs2, nfs3 or nfs4.
Could we rename the module to avoid the alias name collision? Something like this (untested) maybe?
diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
index 8bf3a3f..b7db608 100644
--- a/fs/nfs/Makefile
+++ b/fs/nfs/Makefile
@@ -12,19 +12,19 @@ nfs-$(CONFIG_ROOT_NFS) += nfsroot.o
nfs-$(CONFIG_SYSCTL) += sysctl.o
nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
-obj-$(CONFIG_NFS_V2) += nfs2.o
-nfs2-y := nfs2super.o proc.o nfs2xdr.o
+obj-$(CONFIG_NFS_V2) += nfsv2.o
+nfsv2-y := nfs2super.o proc.o nfs2xdr.o
-obj-$(CONFIG_NFS_V3) += nfs3.o
-nfs3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
-nfs3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
+obj-$(CONFIG_NFS_V3) += nfsv3.o
+nfsv3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
+nfsv3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
-obj-$(CONFIG_NFS_V4) += nfs4.o
-nfs4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
+obj-$(CONFIG_NFS_V4) += nfsv4.o
+nfsv4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
delegation.o idmap.o callback.o callback_xdr.o callback_proc.o \
nfs4namespace.o nfs4getroot.o nfs4client.o
-nfs4-$(CONFIG_SYSCTL) += nfs4sysctl.o
-nfs4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
+nfsv4-$(CONFIG_SYSCTL) += nfs4sysctl.o
+nfsv4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o
nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 9fc0d9d..9969444 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -105,7 +105,7 @@ struct nfs_subversion *get_nfs_version(unsigned int version)
if (IS_ERR(nfs)) {
mutex_lock(&nfs_version_mutex);
- request_module("nfs%d", version);
+ request_module("nfsv%d", version);
nfs = find_nfs_version(version);
mutex_unlock(&nfs_version_mutex);
}
>
> --b.
>
On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
> > On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
> >> On Sat, 4 Aug 2012 15:01:04 -0400
> >> "J. Bruce Fields" <[email protected]> wrote:
> >>
> >>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> >>>> On Fri, 3 Aug 2012 20:08:19 -0400
> >>>> "J. Bruce Fields" <[email protected]> wrote:
> >>>>
> >>>>> I'm getting
> >>>>>
> >>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> >>>>>
> >>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> >>>>> I doubt they're related.)
> >>>>>
> >>>>> Also:
> >>>>>
> >>>>> [root@pip2 ~]# modprobe nfs4
> >>>>> [root@pip2 ~]# lsmod|grep nfs4
> >>>>> [root@pip2 ~]#
> >>>>>
> >>>>> --b.
> >>>>
> >>>> I hit the same problem...
> >>>>
> >>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> >>>> Fedora).
> >>>
> >>> Oog, right.
> >>>
> >>> But, without testing--won't that make v4 mounts fail on older kernels?
> >>
> >> Actually, now that I look, this does not seem to break on older kernels
> >> as long as you use a syntax like:
> >>
> >> # mount -t nfs server:/export /mnt/point -o vers=4
> >>
> >> ...if, however you use a syntax like:
> >>
> >> # mount -t nfs4 server:/export /mnt/point
> >>
> >> ...then it fails without the above file in place. I guess the question
> >> we have to answer is: Do we want to continue to support the "-t nfs4"
> >> mount syntax?
> >
> > I think you're right that we want to deprecate it.
> >
> > Though this is a bit of a harsh way to do it--would have been nice to
> > have some transition period with a warning or something.
>
> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
modprobe configuration, and sure enough I get "No such device".
Maybe you have some initscripts or something else that's loading the
nfs module for you before the mount?
--b.
On 08/08/2012 11:08 AM, Myklebust, Trond wrote:
> On Wed, 2012-08-08 at 10:42 -0400, Bryan Schumaker wrote:
>> So you're suggesting something like this? I can split it into two patches for the final submission, one to rename the modules and one to move the nfs4_fs_type back to nfs.ko.
>
> One patch should suffice, since you can't split this up into something
> that fixes both issues.
>
> Then maybe we can add a separate patch with a MODULE_ALIAS("nfs4") so
> that distros can start removing the /etc/modprobe.conf alias entries.
Sure. That goes in the v4 module?
>
>> diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
>> index 8bf3a3f..b7db608 100644
>> --- a/fs/nfs/Makefile
>> +++ b/fs/nfs/Makefile
>> @@ -12,19 +12,19 @@ nfs-$(CONFIG_ROOT_NFS) += nfsroot.o
>> nfs-$(CONFIG_SYSCTL) += sysctl.o
>> nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
>>
>> -obj-$(CONFIG_NFS_V2) += nfs2.o
>> -nfs2-y := nfs2super.o proc.o nfs2xdr.o
>> +obj-$(CONFIG_NFS_V2) += nfsv2.o
>> +nfsv2-y := nfs2super.o proc.o nfs2xdr.o
>>
>> -obj-$(CONFIG_NFS_V3) += nfs3.o
>> -nfs3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
>> -nfs3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
>> +obj-$(CONFIG_NFS_V3) += nfsv3.o
>> +nfsv3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
>> +nfsv3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
>>
>> -obj-$(CONFIG_NFS_V4) += nfs4.o
>> -nfs4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
>> +obj-$(CONFIG_NFS_V4) += nfsv4.o
>> +nfsv4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
>> delegation.o idmap.o callback.o callback_xdr.o callback_proc.o \
>> nfs4namespace.o nfs4getroot.o nfs4client.o
>> -nfs4-$(CONFIG_SYSCTL) += nfs4sysctl.o
>> -nfs4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
>> +nfsv4-$(CONFIG_SYSCTL) += nfs4sysctl.o
>> +nfsv4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
>>
>> obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o
>> nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o
>> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
>> index 9fc0d9d..9969444 100644
>> --- a/fs/nfs/client.c
>> +++ b/fs/nfs/client.c
>> @@ -105,7 +105,7 @@ struct nfs_subversion *get_nfs_version(unsigned int version)
>>
>> if (IS_ERR(nfs)) {
>> mutex_lock(&nfs_version_mutex);
>> - request_module("nfs%d", version);
>> + request_module("nfsv%d", version);
>> nfs = find_nfs_version(version);
>> mutex_unlock(&nfs_version_mutex);
>> }
>> diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
>> index 19c1a56..43f4971 100644
>> --- a/fs/nfs/nfs4_fs.h
>> +++ b/fs/nfs/nfs4_fs.h
>> @@ -205,6 +205,9 @@ extern const struct dentry_operations nfs4_dentry_operations;
>> int nfs_atomic_open(struct inode *, struct dentry *, struct file *,
>>
>> +/* super.c */
>> +extern struct file_system_type nfs4_fs_type;
>> +
>> /* nfs4namespace.c */
>> rpc_authflavor_t nfs_find_best_sec(struct nfs4_secinfo_flavors *);
>> struct rpc_clnt *nfs4_create_sec_client(struct rpc_clnt *, struct inode *, struct qstr *);
>> diff --git a/fs/nfs/nfs4super.c b/fs/nfs/nfs4super.c
>> index 12a31a9..bd61221 100644
>> --- a/fs/nfs/nfs4super.c
>> +++ b/fs/nfs/nfs4super.c
>> @@ -23,14 +23,6 @@ static struct dentry *nfs4_referral_mount(struct file_system_type *fs_type,
>> static struct dentry *nfs4_remote_referral_mount(struct file_system_type *fs_type,
>> int flags, const char *dev_name, void *raw_data);
>>
>> -static struct file_system_type nfs4_fs_type = {
>> - .owner = THIS_MODULE,
>> - .name = "nfs4",
>> - .mount = nfs_fs_mount,
>> - .kill_sb = nfs_kill_super,
>> - .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
>> -};
>> -
>> static struct file_system_type nfs4_remote_fs_type = {
>> .owner = THIS_MODULE,
>> .name = "nfs4",
>> @@ -344,14 +336,8 @@ static int __init init_nfs_v4(void)
>> if (err)
>> goto out1;
>>
>> - err = register_filesystem(&nfs4_fs_type);
>> - if (err < 0)
>> - goto out2;
>> -
>> register_nfs_version(&nfs_v4);
>> return 0;
>> -out2:
>> - nfs4_unregister_sysctl();
>> out1:
>> nfs_idmap_quit();
>> out:
>> @@ -361,7 +347,6 @@ out:
>> static void __exit exit_nfs_v4(void)
>> {
>> unregister_nfs_version(&nfs_v4);
>> - unregister_filesystem(&nfs4_fs_type);
>> nfs4_unregister_sysctl();
>> nfs_idmap_quit();
>> }
>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>> index ac6a3c5..49b2dfa 100644
>> --- a/fs/nfs/super.c
>> +++ b/fs/nfs/super.c
>> @@ -319,6 +319,15 @@ EXPORT_SYMBOL_GPL(nfs_sops);
>> static void nfs4_validate_mount_flags(struct nfs_parsed_mount_data *);
>> static int nfs4_validate_mount_data(void *options,
>> struct nfs_parsed_mount_data *args, const char *dev_name);
>> +
>> +struct file_system_type nfs4_fs_type = {
>> + .owner = THIS_MODULE,
>> + .name = "nfs4",
>> + .mount = nfs_fs_mount,
>> + .kill_sb = nfs_kill_super,
>> + .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
>> +};
>> +EXPORT_SYMBOL_GPL(nfs4_fs_type);
>> #endif
>>
>> static struct shrinker acl_shrinker = {
>> @@ -326,6 +335,27 @@ static struct shrinker acl_shrinker = {
>> .seeks = DEFAULT_SEEKS,
>> };
>>
>> +#if IS_ENABLED(CONFIG_NFS_V4)
>> +static int __init register_nfs4_fs(void)
>> +{
>> + return register_filesystem(&nfs4_fs_type);
>> +}
>> +
>> +static void unregister_nfs4_fs(void)
>> +{
>> + unregister_filesystem(&nfs4_fs_type);
>> +}
>> +#else
>> +static int __init register_nfs4_fs(void)
>> +{
>> + return 0;
>> +}
>> +
>> +static void unregister_nfs4_fs(void)
>> +{
>> +}
>> +#endif /* CONFIG_NFS_V4 */
>
> Why not put these helpers in the same section as the declaration of
> nfs4_fs_type?
Because I had scrolled away from that section of code when I was writing these functions. I'll move them...
- Bryan
>
>> +
>> /*
>> * Register the NFS filesystems
>> */
>> @@ -337,12 +367,18 @@ int __init register_nfs_fs(void)
>> if (ret < 0)
>> goto error_0;
>>
>> - ret = nfs_register_sysctl();
>> + ret = register_nfs4_fs();
>> if (ret < 0)
>> goto error_1;
>> +
>> + ret = nfs_register_sysctl();
>> + if (ret < 0)
>> + goto error_2;
>> register_shrinker(&acl_shrinker);
>> return 0;
>>
>> +error_2:
>> + unregister_nfs4_fs();
>> error_1:
>> unregister_filesystem(&nfs_fs_type);
>> error_0:
>> @@ -356,6 +392,7 @@ void __exit unregister_nfs_fs(void)
>> {
>> unregister_shrinker(&acl_shrinker);
>> nfs_unregister_sysctl();
>> + unregister_nfs4_fs();
>> unregister_filesystem(&nfs_fs_type);
>> }
>>
>
On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
>> On Sat, 4 Aug 2012 15:01:04 -0400
>> "J. Bruce Fields" <[email protected]> wrote:
>>
>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
>>>> On Fri, 3 Aug 2012 20:08:19 -0400
>>>> "J. Bruce Fields" <[email protected]> wrote:
>>>>
>>>>> I'm getting
>>>>>
>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
>>>>>
>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
>>>>> I doubt they're related.)
>>>>>
>>>>> Also:
>>>>>
>>>>> [root@pip2 ~]# modprobe nfs4
>>>>> [root@pip2 ~]# lsmod|grep nfs4
>>>>> [root@pip2 ~]#
>>>>>
>>>>> --b.
>>>>
>>>> I hit the same problem...
>>>>
>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
>>>> Fedora).
>>>
>>> Oog, right.
>>>
>>> But, without testing--won't that make v4 mounts fail on older kernels?
>>
>> Actually, now that I look, this does not seem to break on older kernels
>> as long as you use a syntax like:
>>
>> # mount -t nfs server:/export /mnt/point -o vers=4
>>
>> ...if, however you use a syntax like:
>>
>> # mount -t nfs4 server:/export /mnt/point
>>
>> ...then it fails without the above file in place. I guess the question
>> we have to answer is: Do we want to continue to support the "-t nfs4"
>> mount syntax?
>
> I think you're right that we want to deprecate it.
>
> Though this is a bit of a harsh way to do it--would have been nice to
> have some transition period with a warning or something.
I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
- Bryan
>
> --b.
>
On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> On Fri, 3 Aug 2012 20:08:19 -0400
> "J. Bruce Fields" <[email protected]> wrote:
>
> > I'm getting
> >
> > # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> >
> > (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > I doubt they're related.)
> >
> > Also:
> >
> > [root@pip2 ~]# modprobe nfs4
> > [root@pip2 ~]# lsmod|grep nfs4
> > [root@pip2 ~]#
> >
> > --b.
>
> I hit the same problem...
>
> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> Fedora).
Oog, right.
But, without testing--won't that make v4 mounts fail on older kernels?
--b.
On 08/08/2012 11:24 AM, Myklebust, Trond wrote:
> On Wed, 2012-08-08 at 11:15 -0400, Bryan Schumaker wrote:
>> On 08/08/2012 11:08 AM, Myklebust, Trond wrote:
>>> On Wed, 2012-08-08 at 10:42 -0400, Bryan Schumaker wrote:
>>>> So you're suggesting something like this? I can split it into two patches for the final submission, one to rename the modules and one to move the nfs4_fs_type back to nfs.ko.
>>>
>>> One patch should suffice, since you can't split this up into something
>>> that fixes both issues.
>>>
>>> Then maybe we can add a separate patch with a MODULE_ALIAS("nfs4") so
>>> that distros can start removing the /etc/modprobe.conf alias entries.
>>
>> Sure. That goes in the v4 module?
>
> No. The nfs module, since that is what calls register_nfs4_fs()...
>
Ok. I'm testing patch 1 now, I'll add in the alias next.
- Bryan
On Fri, 3 Aug 2012 20:08:19 -0400
"J. Bruce Fields" <[email protected]> wrote:
> I'm getting
>
> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
>
> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> I doubt they're related.)
>
> Also:
>
> [root@pip2 ~]# modprobe nfs4
> [root@pip2 ~]# lsmod|grep nfs4
> [root@pip2 ~]#
>
> --b.
I hit the same problem...
Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
Fedora).
--
Jeff Layton <[email protected]>
On Tue, Aug 07, 2012 at 04:10:49PM -0400, Bryan Schumaker wrote:
> On 08/07/2012 03:57 PM, J. Bruce Fields wrote:
> > On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
> >> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
> >>> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
> >>>> On Sat, 4 Aug 2012 15:01:04 -0400
> >>>> "J. Bruce Fields" <[email protected]> wrote:
> >>>>
> >>>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> >>>>>> On Fri, 3 Aug 2012 20:08:19 -0400
> >>>>>> "J. Bruce Fields" <[email protected]> wrote:
> >>>>>>
> >>>>>>> I'm getting
> >>>>>>>
> >>>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> >>>>>>>
> >>>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> >>>>>>> I doubt they're related.)
> >>>>>>>
> >>>>>>> Also:
> >>>>>>>
> >>>>>>> [root@pip2 ~]# modprobe nfs4
> >>>>>>> [root@pip2 ~]# lsmod|grep nfs4
> >>>>>>> [root@pip2 ~]#
> >>>>>>>
> >>>>>>> --b.
> >>>>>>
> >>>>>> I hit the same problem...
> >>>>>>
> >>>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> >>>>>> Fedora).
> >>>>>
> >>>>> Oog, right.
> >>>>>
> >>>>> But, without testing--won't that make v4 mounts fail on older kernels?
> >>>>
> >>>> Actually, now that I look, this does not seem to break on older kernels
> >>>> as long as you use a syntax like:
> >>>>
> >>>> # mount -t nfs server:/export /mnt/point -o vers=4
> >>>>
> >>>> ...if, however you use a syntax like:
> >>>>
> >>>> # mount -t nfs4 server:/export /mnt/point
> >>>>
> >>>> ...then it fails without the above file in place. I guess the question
> >>>> we have to answer is: Do we want to continue to support the "-t nfs4"
> >>>> mount syntax?
> >>>
> >>> I think you're right that we want to deprecate it.
> >>>
> >>> Though this is a bit of a harsh way to do it--would have been nice to
> >>> have some transition period with a warning or something.
> >>
> >> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
> >
> > Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
> > modprobe configuration, and sure enough I get "No such device".
> >
> > Maybe you have some initscripts or something else that's loading the
> > nfs module for you before the mount?
>
> My nfs-common daemon script loads sunrpc, nfs
Yep, that's why you're not seeing it.
> and nfsd but not nfs2, nfs3 or nfs4.
>
> Could we rename the module to avoid the alias name collision? Something like this (untested) maybe?
I don't think that will help.
--b.
>
>
>
> diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
> index 8bf3a3f..b7db608 100644
> --- a/fs/nfs/Makefile
> +++ b/fs/nfs/Makefile
> @@ -12,19 +12,19 @@ nfs-$(CONFIG_ROOT_NFS) += nfsroot.o
> nfs-$(CONFIG_SYSCTL) += sysctl.o
> nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
>
> -obj-$(CONFIG_NFS_V2) += nfs2.o
> -nfs2-y := nfs2super.o proc.o nfs2xdr.o
> +obj-$(CONFIG_NFS_V2) += nfsv2.o
> +nfsv2-y := nfs2super.o proc.o nfs2xdr.o
>
> -obj-$(CONFIG_NFS_V3) += nfs3.o
> -nfs3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
> -nfs3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
> +obj-$(CONFIG_NFS_V3) += nfsv3.o
> +nfsv3-y := nfs3super.o nfs3client.o nfs3proc.o nfs3xdr.o
> +nfsv3-$(CONFIG_NFS_V3_ACL) += nfs3acl.o
>
> -obj-$(CONFIG_NFS_V4) += nfs4.o
> -nfs4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
> +obj-$(CONFIG_NFS_V4) += nfsv4.o
> +nfsv4-y := nfs4proc.o nfs4xdr.o nfs4state.o nfs4renewd.o nfs4super.o nfs4file.o \
> delegation.o idmap.o callback.o callback_xdr.o callback_proc.o \
> nfs4namespace.o nfs4getroot.o nfs4client.o
> -nfs4-$(CONFIG_SYSCTL) += nfs4sysctl.o
> -nfs4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
> +nfsv4-$(CONFIG_SYSCTL) += nfs4sysctl.o
> +nfsv4-$(CONFIG_NFS_V4_1) += pnfs.o pnfs_dev.o
>
> obj-$(CONFIG_PNFS_FILE_LAYOUT) += nfs_layout_nfsv41_files.o
> nfs_layout_nfsv41_files-y := nfs4filelayout.o nfs4filelayoutdev.o
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index 9fc0d9d..9969444 100644
> --- a/fs/nfs/client.c
> +++ b/fs/nfs/client.c
> @@ -105,7 +105,7 @@ struct nfs_subversion *get_nfs_version(unsigned int version)
>
> if (IS_ERR(nfs)) {
> mutex_lock(&nfs_version_mutex);
> - request_module("nfs%d", version);
> + request_module("nfsv%d", version);
> nfs = find_nfs_version(version);
> mutex_unlock(&nfs_version_mutex);
> }
>
>
> >
> > --b.
> >
>
T24gVHVlLCAyMDEyLTA4LTA3IGF0IDE2OjI1IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6
DQo+IE9uIFR1ZSwgQXVnIDA3LCAyMDEyIGF0IDA0OjEwOjQ5UE0gLTA0MDAsIEJyeWFuIFNjaHVt
YWtlciB3cm90ZToNCj4gPiBPbiAwOC8wNy8yMDEyIDAzOjU3IFBNLCBKLiBCcnVjZSBGaWVsZHMg
d3JvdGU6DQo+ID4gPiBPbiBUdWUsIEF1ZyAwNywgMjAxMiBhdCAwMzo0NDo1M1BNIC0wNDAwLCBC
cnlhbiBTY2h1bWFrZXIgd3JvdGU6DQo+ID4gPj4gT24gMDgvMDcvMjAxMiAwMzo0MiBQTSwgSi4g
QnJ1Y2UgRmllbGRzIHdyb3RlOg0KPiA+ID4+PiBPbiBUdWUsIEF1ZyAwNywgMjAxMiBhdCAwMTow
OTozMlBNIC0wNDAwLCBKZWZmIExheXRvbiB3cm90ZToNCj4gPiA+Pj4+IE9uIFNhdCwgNCBBdWcg
MjAxMiAxNTowMTowNCAtMDQwMA0KPiA+ID4+Pj4gIkouIEJydWNlIEZpZWxkcyIgPGJmaWVsZHNA
ZmllbGRzZXMub3JnPiB3cm90ZToNCj4gPiA+Pj4+DQo+ID4gPj4+Pj4gT24gRnJpLCBBdWcgMDMs
IDIwMTIgYXQgMTA6MDA6MzlQTSAtMDQwMCwgSmVmZiBMYXl0b24gd3JvdGU6DQo+ID4gPj4+Pj4+
IE9uIEZyaSwgMyBBdWcgMjAxMiAyMDowODoxOSAtMDQwMA0KPiA+ID4+Pj4+PiAiSi4gQnJ1Y2Ug
RmllbGRzIiA8YmZpZWxkc0BmaWVsZHNlcy5vcmc+IHdyb3RlOg0KPiA+ID4+Pj4+Pg0KPiA+ID4+
Pj4+Pj4gSSdtIGdldHRpbmcNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiAJIyBtb3VudCAtdG5m
cyAtb25mc3ZlcnM9NCBwaXAxOi9leHBvcnRzIC9tbnQvDQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+
Pj4gKE9LLCBhZG1pdHRlZGx5IHRoYXQncyB3aXRoIDMuNi4wLXJjMSArIGEgZmV3IGV4cGVyaW1l
bnRhbCBwYXRjaGVzLCBidXQNCj4gPiA+Pj4+Pj4+IEkgZG91YnQgdGhleSdyZSByZWxhdGVkLikN
Cj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBBbHNvOg0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+
IAlbcm9vdEBwaXAyIH5dIyBtb2Rwcm9iZSBuZnM0DQo+ID4gPj4+Pj4+PiAJW3Jvb3RAcGlwMiB+
XSMgbHNtb2R8Z3JlcCBuZnM0DQo+ID4gPj4+Pj4+PiAJW3Jvb3RAcGlwMiB+XSMgDQo+ID4gPj4+
Pj4+Pg0KPiA+ID4+Pj4+Pj4gLS1iLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBJIGhpdCB0aGUg
c2FtZSBwcm9ibGVtLi4uDQo+ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+IFRyeSByZW1vdmluZyAvdXNy
L2xpYi9tb2Rwcm9iZS5kL25mcy5jb25mIChhc3N1bWluZyB5b3UncmUgcnVubmluZw0KPiA+ID4+
Pj4+PiBGZWRvcmEpLg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gT29nLCByaWdodC4NCj4gPiA+Pj4+
Pg0KPiA+ID4+Pj4+IEJ1dCwgd2l0aG91dCB0ZXN0aW5nLS13b24ndCB0aGF0IG1ha2UgdjQgbW91
bnRzIGZhaWwgb24gb2xkZXIga2VybmVscz8NCj4gPiA+Pj4+DQo+ID4gPj4+PiBBY3R1YWxseSwg
bm93IHRoYXQgSSBsb29rLCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gYnJlYWsgb24gb2xkZXIga2Vy
bmVscw0KPiA+ID4+Pj4gYXMgbG9uZyBhcyB5b3UgdXNlIGEgc3ludGF4IGxpa2U6DQo+ID4gPj4+
Pg0KPiA+ID4+Pj4gICAgICMgbW91bnQgLXQgbmZzIHNlcnZlcjovZXhwb3J0IC9tbnQvcG9pbnQg
LW8gdmVycz00DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gLi4uaWYsIGhvd2V2ZXIgeW91IHVzZSBhIHN5
bnRheCBsaWtlOg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICAjIG1vdW50IC10IG5mczQgc2VydmVy
Oi9leHBvcnQgL21udC9wb2ludA0KPiA+ID4+Pj4NCj4gPiA+Pj4+IC4uLnRoZW4gaXQgZmFpbHMg
d2l0aG91dCB0aGUgYWJvdmUgZmlsZSBpbiBwbGFjZS4gSSBndWVzcyB0aGUgcXVlc3Rpb24NCj4g
PiA+Pj4+IHdlIGhhdmUgdG8gYW5zd2VyIGlzOiBEbyB3ZSB3YW50IHRvIGNvbnRpbnVlIHRvIHN1
cHBvcnQgdGhlICItdCBuZnM0Ig0KPiA+ID4+Pj4gbW91bnQgc3ludGF4Pw0KPiA+ID4+Pg0KPiA+
ID4+PiBJIHRoaW5rIHlvdSdyZSByaWdodCB0aGF0IHdlIHdhbnQgdG8gZGVwcmVjYXRlIGl0Lg0K
PiA+ID4+Pg0KPiA+ID4+PiBUaG91Z2ggdGhpcyBpcyBhIGJpdCBvZiBhIGhhcnNoIHdheSB0byBk
byBpdC0td291bGQgaGF2ZSBiZWVuIG5pY2UgdG8NCj4gPiA+Pj4gaGF2ZSBzb21lIHRyYW5zaXRp
b24gcGVyaW9kIHdpdGggYSB3YXJuaW5nIG9yIHNvbWV0aGluZy4NCj4gPiA+Pg0KPiA+ID4+IEkg
ZGlkbid0IGV4cGVjdCB0aGlzIHRvIGJlIGJyb2tlbiwgYm90aCB3YXlzIG9mIG1vdW50aW5nIHN0
aWxsIHdvcmsgb24gbXkgVk1zIHNvIEkgZXhwZWN0ZWQgdGhlbSB0byB3b3JrIGZvciBldmVyeWJv
ZHkgZWxzZSB0b28uDQo+ID4gPiANCj4gPiA+IEh1aC4gIEp1c3QgY2hlY2tlZCBvbiBhbiBvbGQg
a2VybmVsIHdpdGhvdXQgYW4gImFsaWFzIG5mczQgbmZzIiBpbg0KPiA+ID4gbW9kcHJvYmUgY29u
ZmlndXJhdGlvbiwgYW5kIHN1cmUgZW5vdWdoIEkgZ2V0ICJObyBzdWNoIGRldmljZSIuDQo+ID4g
PiANCj4gPiA+IE1heWJlIHlvdSBoYXZlIHNvbWUgaW5pdHNjcmlwdHMgb3Igc29tZXRoaW5nIGVs
c2UgdGhhdCdzIGxvYWRpbmcgdGhlDQo+ID4gPiBuZnMgbW9kdWxlIGZvciB5b3UgYmVmb3JlIHRo
ZSBtb3VudD8NCj4gPiANCj4gPiBNeSBuZnMtY29tbW9uIGRhZW1vbiBzY3JpcHQgbG9hZHMgc3Vu
cnBjLCBuZnMNCj4gDQo+IFllcCwgdGhhdCdzIHdoeSB5b3UncmUgbm90IHNlZWluZyBpdC4NCj4g
DQo+ID4gYW5kIG5mc2QgYnV0IG5vdCBuZnMyLCBuZnMzIG9yIG5mczQuDQo+ID4gDQo+ID4gQ291
bGQgd2UgcmVuYW1lIHRoZSBtb2R1bGUgdG8gYXZvaWQgdGhlIGFsaWFzIG5hbWUgY29sbGlzaW9u
PyAgU29tZXRoaW5nIGxpa2UgdGhpcyAodW50ZXN0ZWQpIG1heWJlPw0KPiANCj4gSSBkb24ndCB0
aGluayB0aGF0IHdpbGwgaGVscC4NCg0KSXQgc2hvdWxkIGlmIHdlIGFsc28gYWRkIGJhY2sgaW4N
Cg0Kc3RydWN0IGZpbGVfc3lzdGVtX3R5cGUgbmZzNF9mc190eXBlID0gew0KICAgICAgICAub3du
ZXIgICAgICAgICAgPSBUSElTX01PRFVMRSwNCiAgICAgICAgLm5hbWUgICAgICAgICAgID0gIm5m
czQiLA0KICAgICAgICAubW91bnQgICAgICAgICAgPSBuZnNfZnNfbW91bnQsDQogICAgICAgIC5r
aWxsX3NiICAgICAgICA9IG5mc19raWxsX3N1cGVyLA0KICAgICAgICAuZnNfZmxhZ3MgICAgICAg
PSBGU19SRU5BTUVfRE9FU19EX01PVkV8RlNfUkVWQUxfRE9UfEZTX0JJTkFSWV9NT1VOVERBVEEs
DQp9Ow0KDQphbmQgdGhlbiBhZGQgdGhhdCB0byByZWdpc3Rlcl9uZnNfZnMoKS91bnJlZ2lzdGVy
X25mc19mcygpLiBBcyBmYXIgYXMgSQ0KY2FuIHNlZSwgdGhhdCB3aWxsIHRyaWdnZXIgYWxsIHRo
ZSByaWdodCBpbmNhbnRhdGlvbnMgaW4NCm5mc192YWxpZGF0ZV9tb3VudF9kYXRhKCkgdG8gbW91
bnQgYW4gTkZTdjQgZmlsZXN5c3RlbS4NCg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IGRpZmYgLS1n
aXQgYS9mcy9uZnMvTWFrZWZpbGUgYi9mcy9uZnMvTWFrZWZpbGUNCj4gPiBpbmRleCA4YmYzYTNm
Li5iN2RiNjA4IDEwMDY0NA0KPiA+IC0tLSBhL2ZzL25mcy9NYWtlZmlsZQ0KPiA+ICsrKyBiL2Zz
L25mcy9NYWtlZmlsZQ0KPiA+IEBAIC0xMiwxOSArMTIsMTkgQEAgbmZzLSQoQ09ORklHX1JPT1Rf
TkZTKSAgICAgICs9IG5mc3Jvb3Qubw0KPiA+ICBuZnMtJChDT05GSUdfU1lTQ1RMKSAgICs9IHN5
c2N0bC5vDQo+ID4gIG5mcy0kKENPTkZJR19ORlNfRlNDQUNIRSkgKz0gZnNjYWNoZS5vIGZzY2Fj
aGUtaW5kZXgubw0KPiA+ICANCj4gPiAtb2JqLSQoQ09ORklHX05GU19WMikgKz0gbmZzMi5vDQo+
ID4gLW5mczIteSA6PSBuZnMyc3VwZXIubyBwcm9jLm8gbmZzMnhkci5vDQo+ID4gK29iai0kKENP
TkZJR19ORlNfVjIpICs9IG5mc3YyLm8NCj4gPiArbmZzdjIteSA6PSBuZnMyc3VwZXIubyBwcm9j
Lm8gbmZzMnhkci5vDQo+ID4gIA0KPiA+IC1vYmotJChDT05GSUdfTkZTX1YzKSArPSBuZnMzLm8N
Cj4gPiAtbmZzMy15IDo9IG5mczNzdXBlci5vIG5mczNjbGllbnQubyBuZnMzcHJvYy5vIG5mczN4
ZHIubw0KPiA+IC1uZnMzLSQoQ09ORklHX05GU19WM19BQ0wpICs9IG5mczNhY2wubw0KPiA+ICtv
YmotJChDT05GSUdfTkZTX1YzKSArPSBuZnN2My5vDQo+ID4gK25mc3YzLXkgOj0gbmZzM3N1cGVy
Lm8gbmZzM2NsaWVudC5vIG5mczNwcm9jLm8gbmZzM3hkci5vDQo+ID4gK25mc3YzLSQoQ09ORklH
X05GU19WM19BQ0wpICs9IG5mczNhY2wubw0KPiA+ICANCj4gPiAtb2JqLSQoQ09ORklHX05GU19W
NCkgKz0gbmZzNC5vDQo+ID4gLW5mczQteSA6PSBuZnM0cHJvYy5vIG5mczR4ZHIubyBuZnM0c3Rh
dGUubyBuZnM0cmVuZXdkLm8gbmZzNHN1cGVyLm8gbmZzNGZpbGUubyBcDQo+ID4gK29iai0kKENP
TkZJR19ORlNfVjQpICs9IG5mc3Y0Lm8NCj4gPiArbmZzdjQteSA6PSBuZnM0cHJvYy5vIG5mczR4
ZHIubyBuZnM0c3RhdGUubyBuZnM0cmVuZXdkLm8gbmZzNHN1cGVyLm8gbmZzNGZpbGUubyBcDQo+
ID4gICAgICAgICAgIGRlbGVnYXRpb24ubyBpZG1hcC5vIGNhbGxiYWNrLm8gY2FsbGJhY2tfeGRy
Lm8gY2FsbGJhY2tfcHJvYy5vIFwNCj4gPiAgICAgICAgICAgbmZzNG5hbWVzcGFjZS5vIG5mczRn
ZXRyb290Lm8gbmZzNGNsaWVudC5vDQo+ID4gLW5mczQtJChDT05GSUdfU1lTQ1RMKSAgKz0gbmZz
NHN5c2N0bC5vDQo+ID4gLW5mczQtJChDT05GSUdfTkZTX1Y0XzEpICAgICAgICArPSBwbmZzLm8g
cG5mc19kZXYubw0KPiA+ICtuZnN2NC0kKENPTkZJR19TWVNDVEwpICs9IG5mczRzeXNjdGwubw0K
PiA+ICtuZnN2NC0kKENPTkZJR19ORlNfVjRfMSkgICAgICAgKz0gcG5mcy5vIHBuZnNfZGV2Lm8N
Cj4gPiAgDQo+ID4gIG9iai0kKENPTkZJR19QTkZTX0ZJTEVfTEFZT1VUKSArPSBuZnNfbGF5b3V0
X25mc3Y0MV9maWxlcy5vDQo+ID4gIG5mc19sYXlvdXRfbmZzdjQxX2ZpbGVzLXkgOj0gbmZzNGZp
bGVsYXlvdXQubyBuZnM0ZmlsZWxheW91dGRldi5vDQo+ID4gZGlmZiAtLWdpdCBhL2ZzL25mcy9j
bGllbnQuYyBiL2ZzL25mcy9jbGllbnQuYw0KPiA+IGluZGV4IDlmYzBkOWQuLjk5Njk0NDQgMTAw
NjQ0DQo+ID4gLS0tIGEvZnMvbmZzL2NsaWVudC5jDQo+ID4gKysrIGIvZnMvbmZzL2NsaWVudC5j
DQo+ID4gQEAgLTEwNSw3ICsxMDUsNyBAQCBzdHJ1Y3QgbmZzX3N1YnZlcnNpb24gKmdldF9uZnNf
dmVyc2lvbih1bnNpZ25lZCBpbnQgdmVyc2lvbikNCj4gPiAgDQo+ID4gICAgICAgICBpZiAoSVNf
RVJSKG5mcykpIHsNCj4gPiAgICAgICAgICAgICAgICAgbXV0ZXhfbG9jaygmbmZzX3ZlcnNpb25f
bXV0ZXgpOw0KPiA+IC0gICAgICAgICAgICAgICByZXF1ZXN0X21vZHVsZSgibmZzJWQiLCB2ZXJz
aW9uKTsNCj4gPiArICAgICAgICAgICAgICAgcmVxdWVzdF9tb2R1bGUoIm5mc3YlZCIsIHZlcnNp
b24pOw0KPiA+ICAgICAgICAgICAgICAgICBuZnMgPSBmaW5kX25mc192ZXJzaW9uKHZlcnNpb24p
Ow0KPiA+ICAgICAgICAgICAgICAgICBtdXRleF91bmxvY2soJm5mc192ZXJzaW9uX211dGV4KTsN
Cj4gPiAgICAgICAgIH0NCj4gPiANCj4gPiANCj4gPiA+IA0KPiA+ID4gLS1iLg0KPiA+ID4gDQo+
ID4gDQo+IC0tDQo+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5l
ICJ1bnN1YnNjcmliZSBsaW51eC1uZnMiIGluDQo+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBt
YWpvcmRvbW9Admdlci5rZXJuZWwub3JnDQo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6
Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KDQotLSANClRyb25kIE15a2xl
YnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVi
dXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
On Sat, 4 Aug 2012 15:01:04 -0400
"J. Bruce Fields" <[email protected]> wrote:
> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> > On Fri, 3 Aug 2012 20:08:19 -0400
> > "J. Bruce Fields" <[email protected]> wrote:
> >
> > > I'm getting
> > >
> > > # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> > >
> > > (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > > I doubt they're related.)
> > >
> > > Also:
> > >
> > > [root@pip2 ~]# modprobe nfs4
> > > [root@pip2 ~]# lsmod|grep nfs4
> > > [root@pip2 ~]#
> > >
> > > --b.
> >
> > I hit the same problem...
> >
> > Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> > Fedora).
>
> Oog, right.
>
> But, without testing--won't that make v4 mounts fail on older kernels?
>
> --b.
Yeah, possibly. Wonder if we should consider pushing an update to
stable kernels to add a "nfs4" module alias to nfs.ko?
--
Jeff Layton <[email protected]>
On Tue, 7 Aug 2012 21:23:34 +0000
"Myklebust, Trond" <[email protected]> wrote:
> On Tue, 2012-08-07 at 16:25 -0400, J. Bruce Fields wrote:
> > On Tue, Aug 07, 2012 at 04:10:49PM -0400, Bryan Schumaker wrote:
> > > On 08/07/2012 03:57 PM, J. Bruce Fields wrote:
> > > > On Tue, Aug 07, 2012 at 03:44:53PM -0400, Bryan Schumaker wrote:
> > > >> On 08/07/2012 03:42 PM, J. Bruce Fields wrote:
> > > >>> On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
> > > >>>> On Sat, 4 Aug 2012 15:01:04 -0400
> > > >>>> "J. Bruce Fields" <[email protected]> wrote:
> > > >>>>
> > > >>>>> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> > > >>>>>> On Fri, 3 Aug 2012 20:08:19 -0400
> > > >>>>>> "J. Bruce Fields" <[email protected]> wrote:
> > > >>>>>>
> > > >>>>>>> I'm getting
> > > >>>>>>>
> > > >>>>>>> # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> > > >>>>>>>
> > > >>>>>>> (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > > >>>>>>> I doubt they're related.)
> > > >>>>>>>
> > > >>>>>>> Also:
> > > >>>>>>>
> > > >>>>>>> [root@pip2 ~]# modprobe nfs4
> > > >>>>>>> [root@pip2 ~]# lsmod|grep nfs4
> > > >>>>>>> [root@pip2 ~]#
> > > >>>>>>>
> > > >>>>>>> --b.
> > > >>>>>>
> > > >>>>>> I hit the same problem...
> > > >>>>>>
> > > >>>>>> Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> > > >>>>>> Fedora).
> > > >>>>>
> > > >>>>> Oog, right.
> > > >>>>>
> > > >>>>> But, without testing--won't that make v4 mounts fail on older kernels?
> > > >>>>
> > > >>>> Actually, now that I look, this does not seem to break on older kernels
> > > >>>> as long as you use a syntax like:
> > > >>>>
> > > >>>> # mount -t nfs server:/export /mnt/point -o vers=4
> > > >>>>
> > > >>>> ...if, however you use a syntax like:
> > > >>>>
> > > >>>> # mount -t nfs4 server:/export /mnt/point
> > > >>>>
> > > >>>> ...then it fails without the above file in place. I guess the question
> > > >>>> we have to answer is: Do we want to continue to support the "-t nfs4"
> > > >>>> mount syntax?
> > > >>>
> > > >>> I think you're right that we want to deprecate it.
> > > >>>
> > > >>> Though this is a bit of a harsh way to do it--would have been nice to
> > > >>> have some transition period with a warning or something.
> > > >>
> > > >> I didn't expect this to be broken, both ways of mounting still work on my VMs so I expected them to work for everybody else too.
> > > >
> > > > Huh. Just checked on an old kernel without an "alias nfs4 nfs" in
> > > > modprobe configuration, and sure enough I get "No such device".
> > > >
> > > > Maybe you have some initscripts or something else that's loading the
> > > > nfs module for you before the mount?
> > >
> > > My nfs-common daemon script loads sunrpc, nfs
> >
> > Yep, that's why you're not seeing it.
> >
> > > and nfsd but not nfs2, nfs3 or nfs4.
> > >
> > > Could we rename the module to avoid the alias name collision? Something like this (untested) maybe?
> >
> > I don't think that will help.
>
> It should if we also add back in
>
> struct file_system_type nfs4_fs_type = {
> .owner = THIS_MODULE,
> .name = "nfs4",
> .mount = nfs_fs_mount,
> .kill_sb = nfs_kill_super,
> .fs_flags = FS_RENAME_DOES_D_MOVE|FS_REVAL_DOT|FS_BINARY_MOUNTDATA,
> };
>
> and then add that to register_nfs_fs()/unregister_nfs_fs(). As far as I
> can see, that will trigger all the right incantations in
> nfs_validate_mount_data() to mount an NFSv4 filesystem.
>
So, move the nfs4 fstype definition back into nfs.ko? That would
ensure that you could still do a "-t nfs4" mount with that modprobe
alias in place.
I think Bryan is correct though. We'll also need to rename nfs4.ko or
you won't ever be able to call request_module for it in order to plug
it in if you have that module alias in place.
Does this mean that we plan to support the "-t nfs4" mount syntax in
perpetuity?
--
Jeff Layton <[email protected]>
T24gVHVlLCAyMDEyLTA4LTA3IGF0IDE4OjI2IC0wNDAwLCBKZWZmIExheXRvbiB3cm90ZToNCj4g
T24gVHVlLCA3IEF1ZyAyMDEyIDIxOjIzOjM0ICswMDAwDQo+ICJNeWtsZWJ1c3QsIFRyb25kIiA8
VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+IHdyb3RlOg0KPiANCj4gPiBPbiBUdWUsIDIwMTIt
MDgtMDcgYXQgMTY6MjUgLTA0MDAsIEouIEJydWNlIEZpZWxkcyB3cm90ZToNCj4gPiA+IE9uIFR1
ZSwgQXVnIDA3LCAyMDEyIGF0IDA0OjEwOjQ5UE0gLTA0MDAsIEJyeWFuIFNjaHVtYWtlciB3cm90
ZToNCj4gPiA+ID4gT24gMDgvMDcvMjAxMiAwMzo1NyBQTSwgSi4gQnJ1Y2UgRmllbGRzIHdyb3Rl
Og0KPiA+ID4gPiA+IE9uIFR1ZSwgQXVnIDA3LCAyMDEyIGF0IDAzOjQ0OjUzUE0gLTA0MDAsIEJy
eWFuIFNjaHVtYWtlciB3cm90ZToNCj4gPiA+ID4gPj4gT24gMDgvMDcvMjAxMiAwMzo0MiBQTSwg
Si4gQnJ1Y2UgRmllbGRzIHdyb3RlOg0KPiA+ID4gPiA+Pj4gT24gVHVlLCBBdWcgMDcsIDIwMTIg
YXQgMDE6MDk6MzJQTSAtMDQwMCwgSmVmZiBMYXl0b24gd3JvdGU6DQo+ID4gPiA+ID4+Pj4gT24g
U2F0LCA0IEF1ZyAyMDEyIDE1OjAxOjA0IC0wNDAwDQo+ID4gPiA+ID4+Pj4gIkouIEJydWNlIEZp
ZWxkcyIgPGJmaWVsZHNAZmllbGRzZXMub3JnPiB3cm90ZToNCj4gPiA+ID4gPj4+Pg0KPiA+ID4g
PiA+Pj4+PiBPbiBGcmksIEF1ZyAwMywgMjAxMiBhdCAxMDowMDozOVBNIC0wNDAwLCBKZWZmIExh
eXRvbiB3cm90ZToNCj4gPiA+ID4gPj4+Pj4+IE9uIEZyaSwgMyBBdWcgMjAxMiAyMDowODoxOSAt
MDQwMA0KPiA+ID4gPiA+Pj4+Pj4gIkouIEJydWNlIEZpZWxkcyIgPGJmaWVsZHNAZmllbGRzZXMu
b3JnPiB3cm90ZToNCj4gPiA+ID4gPj4+Pj4+DQo+ID4gPiA+ID4+Pj4+Pj4gSSdtIGdldHRpbmcN
Cj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+IAkjIG1vdW50IC10bmZzIC1vbmZzdmVy
cz00IHBpcDE6L2V4cG9ydHMgL21udC8NCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+
IChPSywgYWRtaXR0ZWRseSB0aGF0J3Mgd2l0aCAzLjYuMC1yYzEgKyBhIGZldyBleHBlcmltZW50
YWwgcGF0Y2hlcywgYnV0DQo+ID4gPiA+ID4+Pj4+Pj4gSSBkb3VidCB0aGV5J3JlIHJlbGF0ZWQu
KQ0KPiA+ID4gPiA+Pj4+Pj4+DQo+ID4gPiA+ID4+Pj4+Pj4gQWxzbzoNCj4gPiA+ID4gPj4+Pj4+
Pg0KPiA+ID4gPiA+Pj4+Pj4+IAlbcm9vdEBwaXAyIH5dIyBtb2Rwcm9iZSBuZnM0DQo+ID4gPiA+
ID4+Pj4+Pj4gCVtyb290QHBpcDIgfl0jIGxzbW9kfGdyZXAgbmZzNA0KPiA+ID4gPiA+Pj4+Pj4+
IAlbcm9vdEBwaXAyIH5dIyANCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+IC0tYi4N
Cj4gPiA+ID4gPj4+Pj4+DQo+ID4gPiA+ID4+Pj4+PiBJIGhpdCB0aGUgc2FtZSBwcm9ibGVtLi4u
DQo+ID4gPiA+ID4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4gVHJ5IHJlbW92aW5nIC91c3IvbGliL21v
ZHByb2JlLmQvbmZzLmNvbmYgKGFzc3VtaW5nIHlvdSdyZSBydW5uaW5nDQo+ID4gPiA+ID4+Pj4+
PiBGZWRvcmEpLg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBPb2csIHJpZ2h0Lg0KPiA+
ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBCdXQsIHdpdGhvdXQgdGVzdGluZy0td29uJ3QgdGhh
dCBtYWtlIHY0IG1vdW50cyBmYWlsIG9uIG9sZGVyIGtlcm5lbHM/DQo+ID4gPiA+ID4+Pj4NCj4g
PiA+ID4gPj4+PiBBY3R1YWxseSwgbm93IHRoYXQgSSBsb29rLCB0aGlzIGRvZXMgbm90IHNlZW0g
dG8gYnJlYWsgb24gb2xkZXIga2VybmVscw0KPiA+ID4gPiA+Pj4+IGFzIGxvbmcgYXMgeW91IHVz
ZSBhIHN5bnRheCBsaWtlOg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4gICAgICMgbW91bnQg
LXQgbmZzIHNlcnZlcjovZXhwb3J0IC9tbnQvcG9pbnQgLW8gdmVycz00DQo+ID4gPiA+ID4+Pj4N
Cj4gPiA+ID4gPj4+PiAuLi5pZiwgaG93ZXZlciB5b3UgdXNlIGEgc3ludGF4IGxpa2U6DQo+ID4g
PiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiAgICAgIyBtb3VudCAtdCBuZnM0IHNlcnZlcjovZXhwb3J0
IC9tbnQvcG9pbnQNCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+IC4uLnRoZW4gaXQgZmFpbHMg
d2l0aG91dCB0aGUgYWJvdmUgZmlsZSBpbiBwbGFjZS4gSSBndWVzcyB0aGUgcXVlc3Rpb24NCj4g
PiA+ID4gPj4+PiB3ZSBoYXZlIHRvIGFuc3dlciBpczogRG8gd2Ugd2FudCB0byBjb250aW51ZSB0
byBzdXBwb3J0IHRoZSAiLXQgbmZzNCINCj4gPiA+ID4gPj4+PiBtb3VudCBzeW50YXg/DQo+ID4g
PiA+ID4+Pg0KPiA+ID4gPiA+Pj4gSSB0aGluayB5b3UncmUgcmlnaHQgdGhhdCB3ZSB3YW50IHRv
IGRlcHJlY2F0ZSBpdC4NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBUaG91Z2ggdGhpcyBpcyBh
IGJpdCBvZiBhIGhhcnNoIHdheSB0byBkbyBpdC0td291bGQgaGF2ZSBiZWVuIG5pY2UgdG8NCj4g
PiA+ID4gPj4+IGhhdmUgc29tZSB0cmFuc2l0aW9uIHBlcmlvZCB3aXRoIGEgd2FybmluZyBvciBz
b21ldGhpbmcuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEkgZGlkbid0IGV4cGVjdCB0aGlzIHRv
IGJlIGJyb2tlbiwgYm90aCB3YXlzIG9mIG1vdW50aW5nIHN0aWxsIHdvcmsgb24gbXkgVk1zIHNv
IEkgZXhwZWN0ZWQgdGhlbSB0byB3b3JrIGZvciBldmVyeWJvZHkgZWxzZSB0b28uDQo+ID4gPiA+
ID4gDQo+ID4gPiA+ID4gSHVoLiAgSnVzdCBjaGVja2VkIG9uIGFuIG9sZCBrZXJuZWwgd2l0aG91
dCBhbiAiYWxpYXMgbmZzNCBuZnMiIGluDQo+ID4gPiA+ID4gbW9kcHJvYmUgY29uZmlndXJhdGlv
biwgYW5kIHN1cmUgZW5vdWdoIEkgZ2V0ICJObyBzdWNoIGRldmljZSIuDQo+ID4gPiA+ID4gDQo+
ID4gPiA+ID4gTWF5YmUgeW91IGhhdmUgc29tZSBpbml0c2NyaXB0cyBvciBzb21ldGhpbmcgZWxz
ZSB0aGF0J3MgbG9hZGluZyB0aGUNCj4gPiA+ID4gPiBuZnMgbW9kdWxlIGZvciB5b3UgYmVmb3Jl
IHRoZSBtb3VudD8NCj4gPiA+ID4gDQo+ID4gPiA+IE15IG5mcy1jb21tb24gZGFlbW9uIHNjcmlw
dCBsb2FkcyBzdW5ycGMsIG5mcw0KPiA+ID4gDQo+ID4gPiBZZXAsIHRoYXQncyB3aHkgeW91J3Jl
IG5vdCBzZWVpbmcgaXQuDQo+ID4gPiANCj4gPiA+ID4gYW5kIG5mc2QgYnV0IG5vdCBuZnMyLCBu
ZnMzIG9yIG5mczQuDQo+ID4gPiA+IA0KPiA+ID4gPiBDb3VsZCB3ZSByZW5hbWUgdGhlIG1vZHVs
ZSB0byBhdm9pZCB0aGUgYWxpYXMgbmFtZSBjb2xsaXNpb24/ICBTb21ldGhpbmcgbGlrZSB0aGlz
ICh1bnRlc3RlZCkgbWF5YmU/DQo+ID4gPiANCj4gPiA+IEkgZG9uJ3QgdGhpbmsgdGhhdCB3aWxs
IGhlbHAuDQo+ID4gDQo+ID4gSXQgc2hvdWxkIGlmIHdlIGFsc28gYWRkIGJhY2sgaW4NCj4gPiAN
Cj4gPiBzdHJ1Y3QgZmlsZV9zeXN0ZW1fdHlwZSBuZnM0X2ZzX3R5cGUgPSB7DQo+ID4gICAgICAg
ICAub3duZXIgICAgICAgICAgPSBUSElTX01PRFVMRSwNCj4gPiAgICAgICAgIC5uYW1lICAgICAg
ICAgICA9ICJuZnM0IiwNCj4gPiAgICAgICAgIC5tb3VudCAgICAgICAgICA9IG5mc19mc19tb3Vu
dCwNCj4gPiAgICAgICAgIC5raWxsX3NiICAgICAgICA9IG5mc19raWxsX3N1cGVyLA0KPiA+ICAg
ICAgICAgLmZzX2ZsYWdzICAgICAgID0gRlNfUkVOQU1FX0RPRVNfRF9NT1ZFfEZTX1JFVkFMX0RP
VHxGU19CSU5BUllfTU9VTlREQVRBLA0KPiA+IH07DQo+ID4gDQo+ID4gYW5kIHRoZW4gYWRkIHRo
YXQgdG8gcmVnaXN0ZXJfbmZzX2ZzKCkvdW5yZWdpc3Rlcl9uZnNfZnMoKS4gQXMgZmFyIGFzIEkN
Cj4gPiBjYW4gc2VlLCB0aGF0IHdpbGwgdHJpZ2dlciBhbGwgdGhlIHJpZ2h0IGluY2FudGF0aW9u
cyBpbg0KPiA+IG5mc192YWxpZGF0ZV9tb3VudF9kYXRhKCkgdG8gbW91bnQgYW4gTkZTdjQgZmls
ZXN5c3RlbS4NCj4gPiANCj4gDQo+IFNvLCBtb3ZlIHRoZSBuZnM0IGZzdHlwZSBkZWZpbml0aW9u
IGJhY2sgaW50byBuZnMua28/IFRoYXQgd291bGQNCj4gZW5zdXJlIHRoYXQgeW91IGNvdWxkIHN0
aWxsIGRvIGEgIi10IG5mczQiIG1vdW50IHdpdGggdGhhdCBtb2Rwcm9iZQ0KPiBhbGlhcyBpbiBw
bGFjZS4NCg0KTm8uIEkgbWVhbiB0byBhZGQgYSBzZXBhcmF0ZSBuZnM0X2ZzdHlwZSBkZWZpbml0
aW9uIGluIG5mcy5rbywgYW5kDQpyZWdpc3RlciBpdCBzbyB0aGF0IHRoZSBWRlMgcmVjb2duaXNl
cyB0aGUgJ25mczQnIGZpbGVzeXN0ZW0gbmFtZS4NCg0KPiBJIHRoaW5rIEJyeWFuIGlzIGNvcnJl
Y3QgdGhvdWdoLiBXZSdsbCBhbHNvIG5lZWQgdG8gcmVuYW1lIG5mczQua28gb3INCj4geW91IHdv
bid0IGV2ZXIgYmUgYWJsZSB0byBjYWxsIHJlcXVlc3RfbW9kdWxlIGZvciBpdCBpbiBvcmRlciB0
byBwbHVnDQo+IGl0IGluIGlmIHlvdSBoYXZlIHRoYXQgbW9kdWxlIGFsaWFzIGluIHBsYWNlLg0K
DQpZb3UgZGlkIG5vdGUgbXkgdXNlIG9mIHRoZSB3b3JkICJhbHNvIiBhYm92ZT8NCg0KPiBEb2Vz
IHRoaXMgbWVhbiB0aGF0IHdlIHBsYW4gdG8gc3VwcG9ydCB0aGUgIi10IG5mczQiIG1vdW50IHN5
bnRheCBpbg0KPiBwZXJwZXR1aXR5Pw0KDQpObywgYnV0IEkgYWxzbyBhZ3JlZSB3aXRoIEJydWNl
J3MgcG9pbnQgdGhhdCB3ZSBzaG91bGRuJ3QgcHVsbCB0aGUgcGx1Zw0Kd2l0aG91dCBzb21lIHBy
aW9yIG5vdGljZS4gV2Ugc2hvdWxkIGF0IGxlYXN0IGtlZXAgYW4gZW50cnkgaW4NCkRvY3VtZW50
YXRpb24vZmVhdHVyZS1yZW1vdmFsLXNjaGVkdWxlLnR4dCBmb3IgYSBmZXcga2VybmVsIHJldmlz
aW9ucy4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5l
cg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K
DQo=
T24gV2VkLCAyMDEyLTA4LTA4IGF0IDExOjE1IC0wNDAwLCBCcnlhbiBTY2h1bWFrZXIgd3JvdGU6
DQo+IE9uIDA4LzA4LzIwMTIgMTE6MDggQU0sIE15a2xlYnVzdCwgVHJvbmQgd3JvdGU6DQo+ID4g
T24gV2VkLCAyMDEyLTA4LTA4IGF0IDEwOjQyIC0wNDAwLCBCcnlhbiBTY2h1bWFrZXIgd3JvdGU6
DQo+ID4+IFNvIHlvdSdyZSBzdWdnZXN0aW5nIHNvbWV0aGluZyBsaWtlIHRoaXM/ICBJIGNhbiBz
cGxpdCBpdCBpbnRvIHR3byBwYXRjaGVzIGZvciB0aGUgZmluYWwgc3VibWlzc2lvbiwgb25lIHRv
IHJlbmFtZSB0aGUgbW9kdWxlcyBhbmQgb25lIHRvIG1vdmUgdGhlIG5mczRfZnNfdHlwZSBiYWNr
IHRvIG5mcy5rby4NCj4gPiANCj4gPiBPbmUgcGF0Y2ggc2hvdWxkIHN1ZmZpY2UsIHNpbmNlIHlv
dSBjYW4ndCBzcGxpdCB0aGlzIHVwIGludG8gc29tZXRoaW5nDQo+ID4gdGhhdCBmaXhlcyBib3Ro
IGlzc3Vlcy4NCj4gPiANCj4gPiBUaGVuIG1heWJlIHdlIGNhbiBhZGQgYSBzZXBhcmF0ZSBwYXRj
aCB3aXRoIGEgTU9EVUxFX0FMSUFTKCJuZnM0Iikgc28NCj4gPiB0aGF0IGRpc3Ryb3MgY2FuIHN0
YXJ0IHJlbW92aW5nIHRoZSAvZXRjL21vZHByb2JlLmNvbmYgYWxpYXMgZW50cmllcy4NCj4gDQo+
IFN1cmUuICBUaGF0IGdvZXMgaW4gdGhlIHY0IG1vZHVsZT8NCg0KTm8uIFRoZSBuZnMgbW9kdWxl
LCBzaW5jZSB0aGF0IGlzIHdoYXQgY2FsbHMgcmVnaXN0ZXJfbmZzNF9mcygpLi4uDQoNCi0tIA0K
VHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpU
cm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg0K
On Sat, 4 Aug 2012 15:01:04 -0400
"J. Bruce Fields" <[email protected]> wrote:
> On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> > On Fri, 3 Aug 2012 20:08:19 -0400
> > "J. Bruce Fields" <[email protected]> wrote:
> >
> > > I'm getting
> > >
> > > # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> > >
> > > (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > > I doubt they're related.)
> > >
> > > Also:
> > >
> > > [root@pip2 ~]# modprobe nfs4
> > > [root@pip2 ~]# lsmod|grep nfs4
> > > [root@pip2 ~]#
> > >
> > > --b.
> >
> > I hit the same problem...
> >
> > Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> > Fedora).
>
> Oog, right.
>
> But, without testing--won't that make v4 mounts fail on older kernels?
Actually, now that I look, this does not seem to break on older kernels
as long as you use a syntax like:
# mount -t nfs server:/export /mnt/point -o vers=4
...if, however you use a syntax like:
# mount -t nfs4 server:/export /mnt/point
...then it fails without the above file in place. I guess the question
we have to answer is: Do we want to continue to support the "-t nfs4"
mount syntax?
--
Jeff Layton <[email protected]>
On Tue, Aug 07, 2012 at 01:09:32PM -0400, Jeff Layton wrote:
> On Sat, 4 Aug 2012 15:01:04 -0400
> "J. Bruce Fields" <[email protected]> wrote:
>
> > On Fri, Aug 03, 2012 at 10:00:39PM -0400, Jeff Layton wrote:
> > > On Fri, 3 Aug 2012 20:08:19 -0400
> > > "J. Bruce Fields" <[email protected]> wrote:
> > >
> > > > I'm getting
> > > >
> > > > # mount -tnfs -onfsvers=4 pip1:/exports /mnt/
> > > >
> > > > (OK, admittedly that's with 3.6.0-rc1 + a few experimental patches, but
> > > > I doubt they're related.)
> > > >
> > > > Also:
> > > >
> > > > [root@pip2 ~]# modprobe nfs4
> > > > [root@pip2 ~]# lsmod|grep nfs4
> > > > [root@pip2 ~]#
> > > >
> > > > --b.
> > >
> > > I hit the same problem...
> > >
> > > Try removing /usr/lib/modprobe.d/nfs.conf (assuming you're running
> > > Fedora).
> >
> > Oog, right.
> >
> > But, without testing--won't that make v4 mounts fail on older kernels?
>
> Actually, now that I look, this does not seem to break on older kernels
> as long as you use a syntax like:
>
> # mount -t nfs server:/export /mnt/point -o vers=4
>
> ...if, however you use a syntax like:
>
> # mount -t nfs4 server:/export /mnt/point
>
> ...then it fails without the above file in place. I guess the question
> we have to answer is: Do we want to continue to support the "-t nfs4"
> mount syntax?
I think you're right that we want to deprecate it.
Though this is a bit of a harsh way to do it--would have been nice to
have some transition period with a warning or something.
--b.