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