From: "Ara.T.Howard" Subject: Re: Debian Bug#203077: Locks not released on NFS client reboot Date: Fri, 14 Jan 2005 12:50:43 -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-mx2-b.sourceforge.net ([10.3.1.12] helo=sc8-sf-mx2.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1CpXT9-0007LV-5Q for nfs@lists.sourceforge.net; Fri, 14 Jan 2005 11:50:51 -0800 Received: from harp.ngdc.noaa.gov ([140.172.187.26]) by sc8-sf-mx2.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.41) id 1CpXT7-0001f0-Me for nfs@lists.sourceforge.net; Fri, 14 Jan 2005 11:50:51 -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 thanks trond! i don't know if you remember - but i was complaining about F_SETLKW performace a while back. ;-) sounds like this IS the problem... i poked around the nfs-fag and how-to and didn't see this... if i didn't miss it (quite possible) may suggest it be added? i certainly will volunteer but am unsure of the procedure. kind regards. -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