On Tue, 13 May 2003, Don Lewis wrote: > > I should clarify this statement: I no longer get the odd hangs when it > > comes to client and server interactions when contending a lock established > > on the server and now tested by the client. I still bump into the "client > > isn't woken up in a timely manner after a lock is released by the same or > > another client". Here's the demonstration case with a bit more detail > > from what I presented earlier. The server runs on host cboss, the client > > runs twice on host crash1 on different pty's. In this scenario, each > > client attempts to grab an exclusive lock, potentially blocking, and then > > sleep for 10 seconds (this is with one of the earlier posted patches): > > Try adding the lock_answer() calls I suggested in an earlier message ... I did do this, but on reflection, if I'm using NFSv2 (which I am for the root file system), it sounds like changes to the nlm4 code won't help. I put a similar instance of lock_answer() into nlm_granted_1_svc(), and that seems to have greatly improved the latency for this case. I'll test NFSv3 when I get home this evening. So that change sounds like a winner for that issue. This leaves the problem of getting EACCES back for locks contended by an NFS client against consumers directly on the server, rather than the client retrying. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Network Associates LaboratoriesReceived on Tue May 13 2003 - 12:29:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC