RFC: mount.nfs

DISCUSSION Olaf Kirch 3 participants 6 messages Aug 27, 2004 – Aug 28, 2004

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Olaf Kirch

author

2004-08-27 14:15 UTC #0 lore raw

Please find attached the code for mount.nfs, a drop-in replacement for the nfsmount code in mount(8). If you're adventurous, simply compile, and install in /sbin as mount.nfs.

Beware - this is alpha code I just wrote this morning; I'm running this past this list mostly in order to get feedback.

I rewrote the code almost entirely from scratch, because I felt the old code had gotten a little convoluted. The new code should also be a lot smarter about which NFS and MOUNT versions to try, and which transport protocols. It currently prefers TCP over UDP, because that's what I like better, but if people disagree it's easy to turn this into a compile time option.

NFS unmount is missing at the moment, mostly because mount(8) doesn't support /sbin/umount.%s yet.

There's also no NFSv4 support yet, but if anyone would like to send me patches I will gladly incorporate them. I'm also open to design improvements that may make life for NFSv4 folks easier.

Olaf

Signature · 3 lines

Olaf Kirch     |  The Hardware Gods hate me.
[email protected]   |
---------------+

Trond Myklebust

2004-08-27 18:13 UTC #1 lore raw

P=E5 fr , 27/08/2004 klokka 10:15, skreiv Olaf Kirch:

Quoted 5 lines

Please find attached the code for mount.nfs, a drop-in replacement for the nfsmount code in mount(8). If you're adventurous, simply compile, and install in /sbin as mount.nfs.
=20
Beware - this is alpha code I just wrote this morning; I'm running

Quoted 8 lines

this past this list mostly in order to get feedback.
=20
I rewrote the code almost entirely from scratch, because I felt the old code had gotten a little convoluted. The new code should also be a lot smarter about which NFS and MOUNT versions to try, and which transport protocols. It currently prefers TCP over UDP, because that's what I like better, but if people disagree it's easy to turn this into a compile time option.

Yay! This sort of thing has been on my "TODO" list for some time.

Note though that pmap_getmaps() is not supported on legacy portmappers (I think someone complained that their AIX system broke). This is why the rewrite that is in Fedora Core 2 goes to such lengths to actually "ping" the server.

Also note that ideally, we want to make stuff like this as part of a backend library, then have 3 different programs:
mount.nfs2
mount.nfs3
mount.nfs4
that can be called when the user does

mount -t nfs -onfsvers=3D%d

The reason why I want to split out nfs2 from the nfs3 mount is that at some point in the near future, I'd like to change the filesystem registration to create 'struct file_system_type' entries for NFSv2 and NFSv3. That will enable us to

a) clean up the struct nfs_mount to get rid of all that "struct
socket", version 1 legacy crap
b) be able to enumerate exactly which NFS versions the kernel has
been compiled to support by using 'cat /proc/filesystems'.

Cheers,
Trond

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Olaf Kirch

author

2004-08-27 18:24 UTC #2 lore raw

Quoted 2 lines · Trond Myklebust

Note though that pmap_getmaps() is not supported on legacy portmappers (I think someone complained that their AIX system broke). This is why

In what way do these legacy portmappers fail? Does the PMAP_DUMP actually kill the portmapper? If we are able to safely identify broken portmappers, I assume we can fall back to enumerating the available versions by sending a GETPORT request with version 0, and loop over that range.

I can easily put all that stuff into a library, no problem.

Quoted 2 lines

the rewrite that is in Fedora Core 2 goes to such lengths to actually "ping" the server.

I wasn't aware that Redhat already had a rewrite. I'll take a look.

Quoted 8 lines

Also note that ideally, we want to make stuff like this as part of a backend library, then have 3 different programs:
mount.nfs2
mount.nfs3
mount.nfs4
that can be called when the user does
mount -t nfs -onfsvers=%d

That's fine with me. But I think we still need a mount.nfs, because we need to handle the case where the user doesn't specify an NFS version. Calling all mount.nfsX apps in turn may be a bit awkward.

Quoted 7 lines

The reason why I want to split out nfs2 from the nfs3 mount is that at some point in the near future, I'd like to change the filesystem registration to create 'struct file_system_type' entries for NFSv2 and NFSv3. That will enable us to
a) clean up the struct nfs_mount to get rid of all that "struct
socket", version 1 legacy crap

We can do that now, if we drop the requirement of making the struct backward compatible. We already deduce the kernel API version by looking at the kernel release number, so that can be done safely.

Quoted 2 lines

b) be able to enumerate exactly which NFS versions the kernel has
been compiled to support by using 'cat /proc/filesystems'.

Olaf

Signature · 13 lines

Olaf Kirch     |  The Hardware Gods hate me.
[email protected]   |
---------------+ 


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Trond Myklebust

2004-08-27 19:16 UTC #3 lore raw

P=E5 fr , 27/08/2004 klokka 14:24, skreiv Olaf Kirch:

Quoted 2 lines

In what way do these legacy portmappers fail? Does the PMAP_DUMP actually kill the portmapper? If we are able to safely identify broken portmappers=

Quoted 4 lines

I assume we can fall back to enumerating the available versions by sending a GETPORT request with version 0, and loop over that range. =20
I can easily put all that stuff into a library, no problem.

No, it doesn't kill the portmapper, but it returns an error, and so needs to be dealt with. Putting it in as a fallback case would probably be fine...

Quoted 4 lines

Quoted 2 lines
the rewrite that is in Fedora Core 2 goes to such lengths to actually "ping" the server.
=20
I wasn't aware that Redhat already had a rewrite. I'll take a look.

It's based on some work I did 2 years ago to clean the code up a bit, and put in support for TCP/UDP probing. It also does things like fix up "umount" so that we call the correct revision of the mount protocol (some people like to disable NFSv2 support in mountd for instance)...

Quoted 8 lines

Quoted 8 lines
Also note that ideally, we want to make stuff like this as part of a backend library, then have 3 different programs:
mount.nfs2
mount.nfs3
mount.nfs4
that can be called when the user does
=20
mount -t nfs -onfsvers=3D%d

Quoted 4 lines

=20
That's fine with me. But I think we still need a mount.nfs, because we need to handle the case where the user doesn't specify an NFS version. Calling all mount.nfsX apps in turn may be a bit awkward.

I'm not suggesting that you want to call the mount.nfsX apps in turn, but I'm thinking that a minimal front end (in "mount" itself for instance) could do basic probing for version, then call the appropriate back end (or load it as a library or whatever).
The point is that parsing of the mount options and setting up of the nfs_mount struct (and any future nfsX_mount structs) and calling down into the kernel belongs in version-specific modules.

Quoted 11 lines

Quoted 7 lines
The reason why I want to split out nfs2 from the nfs3 mount is that at some point in the near future, I'd like to change the filesystem registration to create 'struct file_system_type' entries for NFSv2 and NFSv3. That will enable us to
=20
a) clean up the struct nfs_mount to get rid of all that "struct
socket", version 1 legacy crap
=20
We can do that now, if we drop the requirement of making the struct backward compatible. We already deduce the kernel API version by looking at the kernel release number, so that can be done safely.

Sure, and in practice, it boils down to the same thing as you propose as far as that struct mount is concerned. It's just that you get the extra benefit that userland can suddenly figure out which versions of NFS the kernel has been compiled to support.
People do actually still compile NFSv2-only kernels (Linus never misses an opportinity to yell at me every time I send in some patch that breaks that 8-)). In the future we also want to be able to give people the option of NFSv3-only or even NFSv4-only kernels as the older NFS revisions fade into historical oblivion.

Cheers,
Trond

Steve Dickson

2004-08-28 17:21 UTC #4 lore raw

In reply to Olaf Kirch

Quoted 6 lines · Olaf Kirch

Please find attached the code for mount.nfs, a drop-in replacement for the nfsmount code in mount(8). If you're adventurous, simply compile, and install in /sbin as mount.nfs.

Nice!

Quoted 5 lines

There's also no NFSv4 support yet, but if anyone would like to send me patches I will gladly incorporate them. I'm also open to design improvements that may make life for NFSv4 folks easier.

Does it make senses to add NFS4 to this command or create a stand-alone mount.nfs4 command as well? nfs4 is a separate filesystem type....

SteveD.

Olaf Kirch

author

2004-08-28 18:21 UTC #5 lore raw

Quoted 9 lines · Steve Dickson

Quoted 5 lines
There's also no NFSv4 support yet, but if anyone would like to send me patches I will gladly incorporate them. I'm also open to design improvements that may make life for NFSv4 folks easier.
Does it make senses to add NFS4 to this command or create a stand-alone mount.nfs4 command as well? nfs4 is a separate filesystem type....
From a convenience point of view, I think it does make sense to integrate

it _somehow_, because users simply want to type "mount foo:/bar /baz" and have the mount command choose the best NFS version, regardless of how things are done in the kernel. Users will hate us if we make them read the fine print at the bottom of the nfs(5) manual page :)

Whether it ends up calling mount.nfs4 when it finds the server supports NFSv4, or whether that logic is built into mount.nfs itself is probably a matter of what works better for NFSv4 developers. As I said, I'm happy to accept patches...

Olaf

Signature · 13 lines

Olaf Kirch     |  The Hardware Gods hate me.
[email protected]   |
---------------+ 


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs