Re: [RFC][PATCH] client cannot get lock after other client got lock occur network partition.

[Mi Jinlong <mijinlong@cn.fujitsu.com>]

Hi Trond

Trond Myklebust =E5=86=99=E9=81=93:
> On Tue, 2009-11-10 at 17:38 +0800, Mi Jinlong wrote:
>> Hi Trond
>>
>> Trond Myklebust =E5=86=99=E9=81=93:
>>> 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 ?=20
>>>>
>>>> The attached patch can make this case OK, but i am not sure it's g=
ood.
>>> 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 hol=
ds 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?
>=20
> Unless you can think of a fix which works with the current NLM protoc=
ol,
> I'd suggest simply encouraging people to move to a protocol with leas=
e
> based locks: i.e. NFSv4...

Can we add a process(like NFSv4's nfsd4) to call the nlm_gc_hosts() per=
iodically?
At nlm_gc_hosts, then call rpc_ping() to check whether network is OK, i=
f not,
its resource will be release.

thanks,
Mi Jinlong