From: "Ara.T.Howard" Subject: Re: Debian Bug#203077: Locks not released on NFS client reboot Date: Tue, 18 Jan 2005 13:59:46 -0700 (MST) Message-ID: References: <20030727163124.GC19877@perlsupport.com> <16164.29864.268358.781865@gargle.gargle.HOWL> <16871.11926.507904.373575@cse.unsw.edu.au> <1105731817.9604.11.camel@lade.trondhjem.org> Reply-To: "Ara.T.Howard" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Neil Brown , Chip Salzenberg , nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1Cr0SI-0003NF-PT for nfs@lists.sourceforge.net; Tue, 18 Jan 2005 13:00:02 -0800 Received: from harp.ngdc.noaa.gov ([140.172.187.26]) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41) id 1Cr0SG-0004hn-Ay for nfs@lists.sourceforge.net; Tue, 18 Jan 2005 13:00:02 -0800 To: Trond Myklebust In-Reply-To: <1105731817.9604.11.camel@lade.trondhjem.org> Sender: nfs-admin@lists.sourceforge.net Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: On Fri, 14 Jan 2005, Trond Myklebust wrote: > fr den 14.01.2005 Klokka 09:05 (-0700) skreiv Ara.T.Howard: >> On Fri, 14 Jan 2005, Neil Brown wrote: >> >>> So bligh, the client, is running statd (the "status" service), but mussel >>> can not talk to it. This is a problem. >> >> are you saying inbound rpc traffic flowing from server -> client MUST not be >> blocked by the firewall and that it is NOT sufficient to allow ONLY inbound >> rpc traffic client -> server? sorry if this does not make sense - i'm a bit >> out of my domain here... > > Bi-directional RPC traffic must be allowed if you plan on using NLM > locking, since it is callback based. A couple of issues that immediately > spring to mind in the case where the server cannot call the client are: > > - Blocking locks (F_SETLKW) will be hampered since the client > expects the server's lockd daemon to call it back as soon as any > conflicting locks have been released and the lock granted... > > - Server reboot recovery will be broken, since the server's > rpc.statd daemon will be incapable of notifying the clients that > their locks have been lost and need to be recovered. > > Cheers, > Trond > -- > Trond Myklebust to anyone following this thread: this was indeed the problem - we had a firewall rule in place that allowed only one-way traffic. if you are having lock recovery issues look here! cheers. -a -- =============================================================================== | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | When you do something, you should burn yourself completely, like a good | bonfire, leaving no trace of yourself. --Shunryu Suzuki =============================================================================== ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs