On Wed, Dec 02, 2009 at 09:29:03AM -0500, Trond Myklebust wrote: > On Wed, 2009-12-02 at 07:26 -0500, Jeff Layton wrote: > > On Wed, 02 Dec 2009 17:47:04 +0800 > > Mi Jinlong <mijinlong@xxxxxxxxxxxxxx> wrote: > > > > > After a client get lock, it's network partition for some reasons. > > > other client cannot get lock success forever. > > > > > > This patch can avoid this problem using rpc_ping to test client's > > > network when host expired but hold lock. > > > > > > If the client's network is partition, server will release client's > > > lock, other client will get lock success. > > > > > > Signed-off-by: mijinlong@xxxxxxxxxxxxxx > > > > Yikes! That sounds like it'll make locking subject to the reliability > > of the network. I don't think that's a good idea. > > > > What might be more reasonable is to consider implementing something > > like the clear_locks command in Solaris. That is, a way for an admin to > > remove server-side locks held by a client that he knows is never going > > to come back. With that, this sort of thing at least becomes a willful > > act... > > Agreed on both counts. > > We should not be changing the semantics of either NFSv3 or NLM at this > time. That will break existing setups that are treating NFSv3 as being a > stable platform. > As I've said in previous correspondence: NFSv4 already offers lease > based locking. If people are worried about network partitions and/or > locks being held by clients that are dead, then they can switch to that. > > On the other hand, a clear_locks command could be useful in order to > tell a server that a given client is dead. It should be fairly easy to > leverage the existing NSM/statd protocol to implement this. Oh, so all clear_locks does is send an nsm notification? Yeah, that sounds like a completely reasonable project for someone. --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
