linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* NFS locking bug
@ 2001-08-01  2:02 Ragnar Kjørstad
  2001-08-01  9:53 ` Trond Myklebust
  0 siblings, 1 reply; 2+ messages in thread
From: Ragnar Kjørstad @ 2001-08-01  2:02 UTC (permalink / raw)
  To: linux-kernel, nfs

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: NFS locking bug
  2001-08-01  2:02 NFS locking bug Ragnar Kjørstad
@ 2001-08-01  9:53 ` Trond Myklebust
  0 siblings, 0 replies; 2+ messages in thread
From: Trond Myklebust @ 2001-08-01  9:53 UTC (permalink / raw)
  To: Ragnar Kjørstad; +Cc: linux-kernel, nfs

>>>>> " " == Ragnar Kjørstad <kernel@ragnark.vestdata.no> writes:

     > 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?

The NLM lock reclaiming code in the stock 2.4.x kernel is
incomplete. Please apply the patch on

   http://www.fys.uio.no/~trondmy/src/2.4.7/linux-2.4.7-reclaim.dif

Cheers,
   Trond

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-08-01  9:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-01  2:02 NFS locking bug Ragnar Kjørstad
2001-08-01  9:53 ` Trond Myklebust

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).