--=-qz1JacGIU9vvl8rVhpYu
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Have you tried to use NFS over TCP instead of UDP? This way the client
would stablish the connection to the service IP.

Regards

El Wed, 15 de 10 de 2003 a las 16:28, Matthias Drochner escribi?=20
> Hi -
> As things look now, NetBSD NFS clients don't work well together
> with certain HA server clusters, at least the DEC "ASE" thing
> (2 Alpha servers with a shared SCSI bus).
> I'll explain how it fails in my setup:
>=20
> The cluster consists of 2 machines, each one has a node specific
> IP address, "node1" and "node2". A service is tied to another
> IP address, "service1". The service can be located on each of the
> nodes; the corresponding machine has "service1" as an IP address
> alias as long as it provides that service. Is a machine fails,
> the other one takes over the service, the "service1" IP address
> and the filesystems belonging to it on the shared SCSI bus.
> The clients mount the filesystems from the "service1" address;
> they don't need to know the "node?" addresses. NFS file handles
> are preserved on a service relocation, so in theory everything
> should be completely transparent.
> However, due to whatever implementation peculiarities on DEC's
> side, UDP RPC calls are replied from the "node?" address, even
> though sent to the "service1" address by the client.
> What happens now is that NetBSD's "mount_nfs" does a "portmap"
> call to "service1", gets the reply from "node1", puts the "node1"
> address into the mount(2) argument structure and passes it to
> the kernel. This works of course as long as "service1" and
> "node1" refer to the same machine.
> If the service gets relocated to "node2", the kernel still sends
> the NFS client calls to "node1". Even if "node1" gets up again,
> all requests are answered with ESTALE because "service1"'s
> filesystems are not mounted on "node1" anymore.
>=20
> A Solution would require to put the "service1" IP address into
> the mount(2) argument structure.
> Now I'm not sure whether to treat this as NFS specific matter, to
> be solved in higher level mount_nfs code, or a general RPC problem.
> The appended patch tries the latter approach, and it makes NFS
> mounts indeed survive a server switchover. (The "inlen" thing
> is just cleanup.)
> I'm not sure about possible effects on RPC multicasts (or anycasts
> with IPv6?). Is it specified whether such service specifications
> should collapse into a specific node address at portmap time?
>=20
> Comments? Clues?
>=20
> best regards
> Matthias
--=20
Christian Palomino
mailto::zakhrin@freeshell.org
http://www.palominocassain.com
GPG FingerPrint: BFF6 784E 01D1 1722 90C2 276A 00CD 900D 624D 100F

--=-qz1JacGIU9vvl8rVhpYu
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQA/jV/KAM2QDWJNEA8RAsU9AJ93i/+hev83g5q9f8b5bJLbBzp7DACffhQG
E4fgDifzVRgvaft6DHlSwZg=
=hmoe
-----END PGP SIGNATURE-----

--=-qz1JacGIU9vvl8rVhpYu--