RFC: mount.nfs

RFC: mount.nfs

[Olaf Kirch]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

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
-- 
Olaf Kirch     |  The Hardware Gods hate me.
okir@suse.de   |
---------------+ 

[-- Attachment #2: mount.nfs-20040827.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 10158 bytes --]

Re: RFC: mount.nfs

[Trond Myklebust]

P=E5 fr , 27/08/2004 klokka 10:15, skreiv 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.
>=20
> Beware - this is alpha code I just wrote this morning; I'm running
> 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RFC: mount.nfs

[Olaf Kirch]

On Fri, Aug 27, 2004 at 02:13:42PM -0400, Trond Myklebust wrote:
> 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.

> 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.

> 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.

> 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.

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

Olaf
-- 
Olaf Kirch     |  The Hardware Gods hate me.
okir@suse.de   |
---------------+ 


-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RFC: mount.nfs

[Trond Myklebust]

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

> 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.
>=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...

> > 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)...

> > 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
>=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.

> > 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


-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RFC: mount.nfs

[Steve Dickson]

Olaf Kirch wrote:

>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!

>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.


-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: RFC: mount.nfs

[Olaf Kirch]

On Sat, Aug 28, 2004 at 01:21:37PM -0400, Steve Dickson wrote:
> >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
-- 
Olaf Kirch     |  The Hardware Gods hate me.
okir@suse.de   |
---------------+ 


-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs