=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
about a year ago I already asked about nfsprog support and that time Trond
told me that the kernel doesn't support it yet.
Background: We are using both, the ClusterNFSD and the KNFSD on our server
(/etc and /var by the cNFSd and everything else by the knfsd).
Since ClusterNFS is based on unfsd, which only supports NFSv2, we were able
work around the nfsprog problem by simply using knfs for nfsv3 and clustern=
fs
for nfsv2. However, now we would like to use unfs3, but wouldn't like to
switch knfs to NFSv2.
I already looked into the source and it was pretty easy to add nfsprog supp=
ort
by adding a nfsprog variable to the mount structure. However I guess
something like this will never go into the kernel.
Then I tried to figure out how the mountprog variable is read from the kern=
el,
unfortunality I only found out that the fs/nfs/mount_clnt.c isn't even
compiled. So I can only guess that this somehow works via the get_mountport=
()
function from userspace, but so far I didn't find out which kernel functions
are responsible for that.
Can someone help me and tell me what would be the best way to add nfsprog
support to the kernel?
Thanks in advance,
Bernd
PS: Our diskless environment based on ClusterNFS+KNFS really works pretty w=
ell
for more than one year and we only need to reboot the clients in case of an
kernel, glibc or init update. I'm currently writing a howto for that.
=2D --
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: [email protected]
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAfq9VC8BUnAF+ydYRAm7bAJ9eUDSnkyWe7ph7invkXv758PxMCwCggfit
2dqBPsaimV9d6TR5exHaLPo=3D
=3DBKVI
=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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
On Thu, Apr 15, 2004 at 05:50:39PM +0200, Bernd Schubert wrote:
> about a year ago I already asked about nfsprog support and that time Trond
> told me that the kernel doesn't support it yet.
Allow me this dumb question, but what is nfsprog support?
Olaf
--
Olaf Kirch | The Hardware Gods hate me.
[email protected] |
---------------+
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 15 April 2004 19:51, Olaf Kirch wrote:
> Hi,
>
> On Thu, Apr 15, 2004 at 05:50:39PM +0200, Bernd Schubert wrote:
> > about a year ago I already asked about nfsprog support and that time
> > Trond told me that the kernel doesn't support it yet.
>
> Allow me this dumb question, but what is nfsprog support?
>
citing from 'man 5 nfs':
nfsprog=3Dn Use an alternate RPC program number to contact the =09
NFS daemon on the remote host.
This option is useful for hosts that can run multiple NFS servers. The =
=09
default value is 100003 which is the standard RPC NFS daemon program=20
number.
Bernd
=2D --=20
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: [email protected]
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAftcCC8BUnAF+ydYRAoO9AJ4k06PckVxT2NJ/4ybon2qCMNbNugCdFtWD
IXh6ZOKpwDyjPu5yEd8MMMg=3D
=3DjVmV
=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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
=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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 15/04/2004 klokka 11:39, skreiv Bernd Schubert:
> nfsprog=3Dn Use an alternate RPC program number to contact the =09
> NFS daemon on the remote host.
> This option is useful for hosts that can run multiple NFS servers. Th=
e =09
> default value is 100003 which is the standard RPC NFS daemon program=20
> 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?
Cheers,
Trond
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 15/04/2004 klokka 14:31, skreiv Bernd Schubert:
> as I wrote, we want to use NFSv3 for knfs and userspace nfs, just take a=20
> look at the following rpcinfo tables:
>=20
What you are describing sounds like a bug in "mount". In the case where
the user specifies both "port" and "nfsvers", there is no need
whatsoever to consult the portmapper.
I just do not see this as a kernel bug, or as any form of justification
for adding support for the nfsprog hack.
Cheers,
Trond
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi Trond,
sorry for the late response, but as usual I was busy with my main work.
>
> What you are describing sounds like a bug in "mount". In the case where
> the user specifies both "port" and "nfsvers", there is no need
> whatsoever to consult the portmapper.
>
> I just do not see this as a kernel bug, or as any form of justification
> for adding support for the nfsprog hack.
>
It seems I was chasing a phantom *hrmmph*.
After you told me, it might be a bug in "mount", I immedeately checked the
util-linux mount source and didn't find anything wrong.
Today I tried again finding the source of the problem, but now I don't see a
problem at all. Mounting on different ports just works fine, even with the
same nfsversion.
I really have no idea why it didn't work all the time, but now suddenly works.
Sorry for wasting your time,
Bernd