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. Trond -- 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
