| Message ID | 50217649.6010402@netapp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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" <bfields@fieldses.org> 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" <bfields@fieldses.org> 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. > > > -- 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 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" <bfields@fieldses.org> 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" <bfields@fieldses.org> 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. > > > > > > > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Tue, 7 Aug 2012 21:23:34 +0000 "Myklebust, Trond" <Trond.Myklebust@netapp.com> 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" <bfields@fieldses.org> 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" <bfields@fieldses.org> 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?
On Tue, 2012-08-07 at 18:26 -0400, Jeff Layton wrote: > On Tue, 7 Aug 2012 21:23:34 +0000 > "Myklebust, Trond" <Trond.Myklebust@netapp.com> 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" <bfields@fieldses.org> 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" <bfields@fieldses.org> 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. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Tue, 7 Aug 2012 22:36:12 +0000 "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Tue, 2012-08-07 at 18:26 -0400, Jeff Layton wrote: > > On Tue, 7 Aug 2012 21:23:34 +0000 > > "Myklebust, Trond" <Trond.Myklebust@netapp.com> 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" <bfields@fieldses.org> 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" <bfields@fieldses.org> 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...
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); }