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

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2009-11-10 at 17:38 +0800, Mi Jinlong wrote:
> Hi Trond
>=20
> 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.
> >=20
> > Unfortunately, NLM (the NFSv2 and v3 locking protocol) is not lease
> > based, so the above scenario is truly an unfixable one.
> >=20
> > 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".
>=20
> Thanks for your answer!
>=20
> 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...

Cheers
  Trond