Hi Trond Trond Myklebust 写道: > On Tue, 2009-11-10 at 17:38 +0800, Mi Jinlong wrote: >> Hi Trond >> >> Trond Myklebust 写道: >>> On Mon, 2009-11-09 at 17:19 +0800, Mi Jinlong wrote: >>>> Hi Trond et all >>>> >>>> There is a bug, when i test NFSv3 file's lock as followed: >>>> >>>> Step1: ClientA and ClientB open a same nfs file; >>>> Step2: ClientA locks file with write lock, it's ok; >>>> Step3: Cut off the network between ClientA and Server; >>>> Step4: ClientB can not acquire for write lock successful forever, even though >>>> the network partition larger than NLM_HOST_EXPIRE. >>>> >>>> As i know, If use NFSv4, step4 can success after LEASE_TIME. >>>> >>>> Is it necessary to fix NFSv3 ? >>>> >>>> The attached patch can make this case OK, but i am not sure it's good. >>> Unfortunately, NLM (the NFSv2 and v3 locking protocol) is not lease >>> based, so the above scenario is truly an unfixable one. >>> >>> The problem with applying your patch is, in essence, that we risk >>> breaking another scenario where a client grabs a lock, and then holds it >>> for a while. >>> The reason this breaks is that there is no equivalent in the NLM >>> protocol of the NFSv4 RENEW operation to tell the server that "This >>> client is still alive and wants you to keep its state". >> Thanks for your answer! >> >> This bug seems serious, shouldn't we fix it? > > Unless you can think of a fix which works with the current NLM protocol, > I'd suggest simply encouraging people to move to a protocol with lease > based locks: i.e. NFSv4... Can we add a process(like NFSv4's nfsd4) to call the nlm_gc_hosts() periodically? At nlm_gc_hosts, then call rpc_ping() to check whether network is OK, if not, its resource will be release. thanks, Mi Jinlong -- 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
