On Thu, Aug 04, 2011 at 12:30:19PM +0200, Frank van Maarseveen wrote:
> Both client- and server run 2.6.39.3, NFSv3 over UDP (without the
> relock_filesystem patch proposed earlier).
>
> A second client has an exclusive lock on a file on the server. The
> client under test calls fcntl(F_SETLKW) to wait for the same exclusive
> lock. Wireshark sees NLM V4 LOCK calls resulting in NLM_BLOCKED.
>
> Next the server is rebooted. The second client recovers the lock
> correctly. The client under test now receives NLM_DENIED_GRACE_PERIOD for
> every NLM V4 LOCK request resulting from the waiting fcntl(F_SETLKW). When
> this changes to NLM_BLOCKED after grace period expiration the fcntl
> returns -ENOLCK ("No locks available.") instead of continuing to wait.
So that sounds like a client bug, and correct behavior from the server
(assuming the second client was still holding the lock throughout).
> server:/proc/locks shows two entries for the file after the -ENOLCK. When
> the second client gives up its lock because the program running there
> is killed one entry in server:/proc/locks remains indefinately: as a
> result no NFS client can lock the file anymore.
But that sounds like a server bug--what do the two entries look like?
Also, what filesystem are you exporting?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
