Hi,
After looking at how the lockd client side is implemented, it seems to me that
lockd tunneling raises no real difficulty. Indeed, the client is busy waiting,
thus it doesn't really matter that the GRANTED/GRANTED_RES callback is lost.
However, with the rpc tunneling I use, if all the nfs mounts are mounted with
the same lockd rpc number, it isn't possible to make a difference between
hosts, thus tunneling is possible, but with only one server.
Will the the lockd client side be redesigned (in such a way that losing server
callbacks becomes an issue) ?
If not, could it be possible to have a lockprog= in the mount arguments ? I
have some ideas on how to implement that on the lockd client side, and it
doesn't seems so hard to do, however I have no idea about the nfs/mount changes
it would require.
Now, on the statd side, it seems to me that it could be possible for the server
to monitor the host issuing the lock demand, by looking at the caller_name
field, instead of relaying on the source of the rpc request. It would involve
some code change in the host lookup part of lockd, but not so much, I think.
Another way to achieve the same goal would be to implement non monitored lockd
clients using the NM_LOCK and the FREE_ALL callbacks, but it is a bad solution
because it forbids blocking locks.
However, on the client side, I can't see any possibility for lockd to get the
real server to monitor. Of course, the rpc forwarder knows that, but there is
nothing which permits it to tell it to the lockd client.
There could be a possibility, but it is out of the lockd scope: the forwarder
could do the monitoring and reclaim the locks. However it is quite bad, because
this would mean reimplementing a quasi complete lockd client in the forwarder
which would have to be aware of the accepted locks, and so on.
Any thought about that ?
Pat
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs