NFS locking bug

Ragnar Kjørstad (kernel@ragnark.vestdata.no)
Wed, 1 Aug 2001 04:02:56 +0200


Let me first ask if I've understood this correctly:
Is statd on the NFS-server supposed to keep track of all NFS-clients
that have locks on the server?
And if the NFS-server gets restarted, statd look at the list of clients
that held locks, and notify them about the restart?
And then statd/lockd on the clientside will relock the files, to make
sure no other clients can lock the same file?

This is what I do:
* mount NFS filesystem on client1
* mount NFS filesystem on client2
* lock file on client1
* verify that I can not lock the same file on client2
* reboot the NFS-server
* When I start statd on the nfs-server, I see the following
in the logfiles for the clients:

Jul 31 18:33:55 client rpc.statd[455]: recv_rply: [127.0.0.1] RPC status 3
Jul 31 18:33:55 client kernel: svc: unknown procedure (24)
Jul 31 18:34:01 client kernel: svc: unknown procedure (24)
Jul 31 18:34:01 client rpc.statd[455]: recv_rply: [127.0.0.1] RPC status 3
Jul 31 18:34:07 client kernel: svc: unknown procedure (24)
Jul 31 18:34:07 client rpc.statd[455]: recv_rply: [127.0.0.1] RPC status 3
Jul 31 18:34:13 client kernel: svc: unknown procedure (24)
Jul 31 18:34:13 client rpc.statd[455]: recv_rply: [127.0.0.1] RPC status 3
Jul 31 18:34:19 client rpc.statd[455]: Can't callback client (100021,1), giving up.

* I can no lock the file on client2, even if the client1 still thinks
the file is locked.

Is this a bug?

-- 
Ragnar Kjorstad
Big Storage

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/