From: Bernd Schubert <bernd-schubert@web.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Olaf Kirch <okir@suse.de>, nfs@lists.sourceforge.net
Subject: Re: nfsprog support
Date: Thu, 15 Apr 2004 23:31:37 +0200 [thread overview]
Message-ID: <200404152331.47440.bernd-schubert@web.de> (raw)
In-Reply-To: <1082057977.7141.31.camel@lade.trondhjem.org>
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 15 April 2004 21:39, Trond Myklebust wrote:
> P=E5 to , 15/04/2004 klokka 11:39, skreiv Bernd Schubert:
> > nfsprog=3Dn Use an alternate RPC program number to contact the
> > NFS daemon on the remote host.
> > This option is useful for hosts that can run multiple NFS servers.=20
> > The default value is 100003 which is the standard RPC NFS daemon progr=
am
> > number.
>
> So, just out of curiosity... Why would anyone prefer to do this rather
> than just having the NFS servers run on different ports, and then using
> the 'port=3D' option?
>
> AFAICS, the only difference there is that you get somewhat dubious extra
> support in the form of a separate portmapper entry for each NFS daemon.
> However given that you still have to feed the NFS client the special
> "nfsprog" number, is there really any benefit to doing this over just
> fixing a set of alternate port numbers that your "mount" can probe?
>
Hello Trond,
as I wrote, we want to use NFSv3 for knfs and userspace nfs, just take a=20
look at the following rpcinfo tables:
Only the kernel nfs daemon is running:
beno:/home/bernd/src/unfs3/unfs3-0.9.8# /etc/init.d/nfs-kernel-server start
Exporting directories for NFS kernel daemon...done.
Starting NFS kernel daemon: nfsd mountd.
beno:/home/bernd/src/unfs3/unfs3-0.9.8# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
391002 2 tcp 679 sgi_fam
100024 1 udp 795 status
100024 1 tcp 798 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 32775 nlockmgr
100021 3 udp 32775 nlockmgr
100021 4 udp 32775 nlockmgr
100021 1 tcp 32774 nlockmgr
100021 3 tcp 32774 nlockmgr
100021 4 tcp 32774 nlockmgr
100005 1 udp 931 mountd
100005 1 tcp 934 mountd
100005 2 udp 931 mountd
100005 2 tcp 934 mountd
100005 3 udp 931 mountd
100005 3 tcp 934 mountd
Now I start the unfs3 daemon on port 2050:
beno:/home/bernd/src/unfs3/unfs3-0.9.8# ./unfsd -n 2050
beno:/home/bernd/src/unfs3/unfs3-0.9.8# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
391002 2 tcp 679 sgi_fam
100024 1 udp 795 status
100024 1 tcp 798 status
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D> here the old (knfsd) information disappeared
100021 1 udp 32775 nlockmgr
100021 3 udp 32775 nlockmgr
100021 4 udp 32775 nlockmgr
100021 1 tcp 32774 nlockmgr
100021 3 tcp 32774 nlockmgr
100021 4 tcp 32774 nlockmgr
100005 2 udp 931 mountd
100005 2 tcp 934 mountd
100003 3 udp 2050 nfs
100003 3 tcp 2050 nfs
100005 1 udp 938 mountd
100005 3 udp 938 mountd
100005 1 tcp 939 mountd
100005 3 tcp 939 mountd
You can see that the previous program: 100003 vers: 3 nfs information hav=
e disappeared.
As I expected, mounting on port 2049 with nfsvers=3D3 now fails:
beno:/home/bernd/src/unfs3/unfs3-0.9.8# mount -t nfs -o port=3D2049,nfsvers=
=3D3 localhost:/home /mnt/test1
NFSv3 not supported!
mount: wrong fs type, bad option, bad superblock on localhost:/home,
or too many mounted file systems
Of course it also works if one only runs the knfsd or if one specifies nfsv=
ers=3D2.
On port 2050 with unfsd it works, of course:
beno:/home/bernd/src/unfs3/unfs3-0.9.8# mount -t nfs -o port=3D2050,nfsvers=
=3D3 localhost:/home /mnt/test2
beno:/home/bernd/src/unfs3/unfs3-0.9.8#
What you suggested is our current workaround, cNFS runs NFSv2=20
and kNFS runs NFSv3. However, as I wrote, with unfs3 we would like to=20
run NFSv3 for both. AFAIK this only works by running one of the daemons
on another rpc-program number.
Thanks,
Bernd
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAfv8/C8BUnAF+ydYRAiDsAKCBJYDiAci7FmYGnTj5PhyFVUoYRACdHaWz
S5qjzka+YxqNM0th9Bd0QYI=3D
=3DX8lX
=2D----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-04-15 21:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-15 15:50 nfsprog support Bernd Schubert
2004-04-15 17:51 ` Olaf Kirch
2004-04-15 18:39 ` Bernd Schubert
2004-04-15 19:39 ` Trond Myklebust
2004-04-15 21:31 ` Bernd Schubert [this message]
2004-04-15 21:43 ` Trond Myklebust
2004-05-02 23:27 ` Bernd Schubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200404152331.47440.bernd-schubert@web.de \
--to=bernd-schubert@web.de \
--cc=nfs@lists.sourceforge.net \
--cc=okir@suse.de \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.