Re: [PATCH 0/3] NLM: Proposal for a timeout setting on blocking locks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-03-12 at 12:26 +0100, Mikael Davranche wrote:
> The only reason why I propose this short serie of patchs is that there is one
> case in which we can not use the NLM_GRANTED mechanism and in which we must
> always use the retransmission+timeout failsafe: the NFS server is under HPUX.
> 
> Let's have a look at the comment of the nlmclnt_lock function:
> 
> 473 /*
> 474  * LOCK: Try to create a lock
> 475  *
> 476  *                      Programmer Harassment Alert
> 477  *
> 478  * When given a blocking lock request in a sync RPC call, the HPUX lockd
> 479  * will faithfully return LCK_BLOCKED but never cares to notify us when
> 480  * the lock could be granted. This way, our local process could hang
> 481  * around forever waiting for the callback.
> 482  *
> 483  *  Solution A: Implement busy-waiting
> 484  *  Solution B: Use the async version of the call (NLM_LOCK_{MSG,RES})
> 485  *
> 486  * For now I am implementing solution A, because I hate the idea of
> 487  * re-implementing lockd for a third time in two months. The async
> 488  * calls shouldn't be too hard to do, however.
> 489  *
> 490  * This is one of the lovely things about standards in the NFS area:
> 491  * they're so soft and squishy you can't really blame HP for doing this.
> 492  */
> 
> Note that I made my tests using a NetApp NAS ;) Indeed, Data ONTAP only sends
> NLM_GRANTED over UDP (not TCP). So we can reproduce the HPUX behaviour with
> "nlm_udpport = 0" on the client.

Yes, but that HPUX case is a very old server bug (at least 10 years
old), and I'd assume it has been fixed by now. Even if it hasn't, I'm
not going to bend over backwards in the client code to fix a server that
is in obvious violation of the NLM protocol.

We fix server bugs on the server and client bugs on the client.

Cheers
   Trond

-- 
Trond Myklebust
NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux