Hi,
I admit the subject is rather cryptic. Here is the explaination.
It seems to me that the hosts structure is common to all the lockd clients and
the lockd server. Is it true (because nlm_hosts is a static array) ?
If it is true, then it seems to me that there is a problem with the fact that
the rpc clients are tied to hosts. If there is a client allready defined, it is
used, although it may have incorrect settings with respect with softrtry,
chatty and intr. Otherwise said, the first rpc call determines the client
options. I think this is not what should be.
Should I try to correct it (if the hosts are really shared) ?
Pat
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Patrice DUMAS <[email protected]> writes:
> It seems to me that the hosts structure is common to all the
> lockd clients and the lockd server. Is it true (because
> nlm_hosts is a static array) ?
The structure is common, but the entries shouldn't be.
Hmm... It looks like nlm_match_host() might want a small fix in order
to take that into account...
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
>
> > It seems to me that the hosts structure is common to all the
> > lockd clients and the lockd server. Is it true (because
> > nlm_hosts is a static array) ?
>
> The structure is common, but the entries shouldn't be.
>
> Hmm... It looks like nlm_match_host() might want a small fix in order
> to take that into account...
;-)
To do that, there should be a way to differenciate between different clients
and the server. Have the different clients a different pid, also different from
the server (or the kernel equivalent of a pid), and how can I get that
information ?
Also, I had another idea in order to fix it. Just keep the hosts common, but
add a chained list of clients differing by the softrtry, chatty,... to the
host. Then change nlm_bind_host to add a support for different clients
matching. I prefer this solution because in the GRANT implementation I did,
there is a need to change the softrtry and this could interfere with other
calls from the server if there is just one client for a host.
What do you think about that ?
Pat
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Patrice DUMAS <[email protected]> writes:
> To do that, there should be a way to differenciate between
> different clients and the server. Have the different clients a
> different pid, also different from the server (or the kernel
> equivalent of a pid), and how can I get that information ?
The server should always be indexing entries by the struct svc_client
(which of course does not exist for the client).
IOW the code could instead simply read
static inline int
nlm_match_host(struct nlm_host *host, struct svc_client *clnt,
struct sockaddr_in *sin)
{
if (clnt || host->h_exportent)
return host->h_exportent == clnt;
return nlm_cmp_addr(&host->h_addr, sin);
}
Of course, keeping 2 separate lists would make a lot of sense, and
could allow us to make other rationalizations.
> Also, I had another idea in order to fix it. Just keep the
> hosts common, but add a chained list of clients differing by
> the softrtry, chatty,... to the host. Then change nlm_bind_host
> to add a support for different clients matching. I prefer this
> solution because in the GRANT implementation I did, there is a
> need to change the softrtry and this could interfere with other
> calls from the server if there is just one client for a host.
Not sure I understand this. Why do you need soft in one case, and not
soft in the other?
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
> The server should always be indexing entries by the struct svc_client
> (which of course does not exist for the client).
This will clean things for client/server mix, but not for client/client mix.
Just suppose a client is waiting for a lock, and another lock is requested, but
with different softtrtry, etc... settings. The second one will use the same
than the first (from nlmclnt_proc):
/* Create RPC client handle if not there, and copy soft
* and intr flags from NFS client. */
if (host->h_rpcclnt == NULL) {
struct rpc_clnt *clnt;
/* Bind an rpc client to this host handle (does not
* perform a portmapper lookup) */
if (!(clnt = nlm_bind_host(host))) {
status = -ENOLCK;
goto done;
}
clnt->cl_softrtry = nfssrv->client->cl_softrtry;
clnt->cl_intr = nfssrv->client->cl_intr;
clnt->cl_chatty = nfssrv->client->cl_chatty;
}
> IOW the code could instead simply read
>
> static inline int
> nlm_match_host(struct nlm_host *host, struct svc_client *clnt,
> struct sockaddr_in *sin)
> {
> if (clnt || host->h_exportent)
> return host->h_exportent == clnt;
> return nlm_cmp_addr(&host->h_addr, sin);
> }
Your stuff should be right to isolate server and clients hosts.
The nlmclnt_lookup_host in server code should also be replaced with
nlmsvc_lookup_host... hoping it won't break anything ;-).
> Not sure I understand this. Why do you need soft in one case, and not
> soft in the other?
In case the client asked with LOCK (and not LOCK_MSG), the server will try to
grant the lock with GRANTED. However some clients only accept GRANTED_MSG even
if they asked with LOCK. If the call is hard, the server will never know that
the client doesn't respond to the GRANTED call. My strategy is be to do the
GRANTED call soft, and revert to GRANTED_MSG if getting an EIO. (the
GRANTED_MSG being still hard). Does it make sense ?
Pat
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs