i have a question regarding rpc.statd and it's reporting of hostname. in the
case of a multi-homed client, say one running nfs on the
client.b.domain
interface. rpc.statd must be forced to report itself as 'client.b.domain'
lest lockd recovery fail when it reports client.domain. this is all well and
good - but what if you have nfs running on more than one interface, like the
case of home dirs on front-door and file-server on back-door? now what can
you do? if you specify the hostname for rpc.statd you'll break lock recovery
on one or the other filesystem right?
i'm thinking that rpc.statd needs to be able to report as a user specified
name for each mounted filesystem - eg. a mount option. if this were done
fstab could look something like
moby.b:/raid/array0/part1/export on /dmsp/moby-0-1 type nfs (rw,bg,hard,intr,rsize=8192,wsize=8192,addr=10.1.186.54,hostname=client.b.domain)
moby:/raid/array0/part2/export on /home type nfs (rw,bg,hard,intr,rsize=8192,wsize=8192,addr=10.1.186.54,hostname=client.domain)
of course, there is already the 'mounthost' option - if all mounted
filesystems specified this as `uname -n` whould this make lock recovery work
for all interfaces?
obviously i know very little about this but am wondering what the best way to
make lock recovery work for mutil-homed clients mounting filesystems on > 1
interface.
kind regards.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
hi ara-
statd is a user-level thing. it has nothing to do with mount or the
mount options.
everything should work properly with multi-homed clients as long as each
client consistently uses the same unique hostname for both lockd and
statd requests, as far as i can tell.
> -----Original Message-----
> From: Ara.T.Howard [mailto:[email protected]]=20
> Sent: Wednesday, February 02, 2005 1:42 PM
> To: [email protected]
> Subject: [NFS] rpc.statd -n
>=20
>=20
>=20
> i have a question regarding rpc.statd and it's reporting of=20
> hostname. in the
> case of a multi-homed client, say one running nfs on the
>=20
> client.b.domain
>=20
> interface. rpc.statd must be forced to report itself as=20
> 'client.b.domain'
> lest lockd recovery fail when it reports client.domain. this=20
> is all well and
> good - but what if you have nfs running on more than one=20
> interface, like the
> case of home dirs on front-door and file-server on back-door?=20
> now what can
> you do? if you specify the hostname for rpc.statd you'll=20
> break lock recovery
> on one or the other filesystem right?
>=20
> i'm thinking that rpc.statd needs to be able to report as a=20
> user specified
> name for each mounted filesystem - eg. a mount option. if=20
> this were done
> fstab could look something like
>=20
> moby.b:/raid/array0/part1/export on /dmsp/moby-0-1 type=20
> nfs=20
> (rw,bg,hard,intr,rsize=3D8192,wsize=3D8192,addr=3D10.1.186.54,hostna
> me=3Dclient.b.domain)
> moby:/raid/array0/part2/export on /home type nfs=20
> (rw,bg,hard,intr,rsize=3D8192,wsize=3D8192,addr=3D10.1.186.54,hostna
> me=3Dclient.domain)
>=20
> of course, there is already the 'mounthost' option - if all mounted
> filesystems specified this as `uname -n` whould this make=20
> lock recovery work
> for all interfaces?
>=20
> obviously i know very little about this but am wondering what=20
> the best way to
> make lock recovery work for mutil-homed clients mounting=20
> filesystems on > 1
> interface.
>=20
> kind regards.
>=20
> -a
> --=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=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
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> | PHONE :: 303.497.6469
> | When you do something, you should burn yourself completely,=20
> like a good
> | bonfire, leaving no trace of yourself. --Shunryu Suzuki
> =
=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=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
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20
> Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2 Feb 2005, Lever, Charles wrote:
thanks for the info charles-
> statd is a user-level thing.
i though only lockd could be userland?
> it has nothing to do with mount or the mount options.
i realize that - i'm just suggesting that it should since nlm is all it's used
for.
> everything should work properly with multi-homed clients as long as each
> client consistently uses the same unique hostname for both lockd and
> statd requests, as far as i can tell.
how can that be? in our situation nfs runs on the back-door so server sees
client as
client.b.ngdc.noaa.gov
now, lockd recovery fails UNLESS '-n' argument is given to rpc.statd.
however, having given the back-door name to statd, if we were to mount a
filesystem on the frontdoor this name will then be incorrect for lock recovery
on THAT server! it seems to me that the reason this is true is exactly the
reason our recovery was failing in the first place: the hostname used by
rpc.statd has nothing to do with which interface the nfs/lockd communication
was done using and, therefore, who the server thinks holds the lock.
i HOPE i'm mistaken but this is my current (limited) understanding of the
situation.
cheers.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Feb 02, 2005 at 11:41:52AM -0700, Ara.T.Howard wrote:
> i have a question regarding rpc.statd and it's reporting of hostname. =
in=20
> the
> case of a multi-homed client, say one running nfs on the
>=20
> client.b.domain
>=20
> interface. rpc.statd must be forced to report itself as 'client.b.doma=
in'
> lest lockd recovery fail when it reports client.domain. this is all we=
ll=20
> and
> good - but what if you have nfs running on more than one interface, lik=
e the
> case of home dirs on front-door and file-server on back-door? now what=
can
> you do? if you specify the hostname for rpc.statd you'll break lock=20
> recovery
> on one or the other filesystem right?
Search the archives for "STATD - SM_NOTIFY have wrong ID_NAME on
multihost servers".
--=20
Ragnar Kj=F8rstad
Software Engineer
Scali - http://www.scali.com
High Performance Clustering
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2 Feb 2005, Ragnar [iso-8859-15] Kj?rstad wrote:
> Search the archives for "STATD - SM_NOTIFY have wrong ID_NAME on
> multihost servers".
illuminating.
i hope this doesn't get forgotten...
thanks.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================