From owner-freebsd-fs@FreeBSD.ORG Fri Sep 18 07:14:38 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCDF31065679 for ; Fri, 18 Sep 2009 07:14:38 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7918FC14 for ; Fri, 18 Sep 2009 07:14:38 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id n8I7EZFU004020; Fri, 18 Sep 2009 09:14:36 +0200 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 47E5024; Fri, 18 Sep 2009 09:14:35 +0200 (CEST) Date: Fri, 18 Sep 2009 09:14:35 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Rick Macklem Message-Id: <20090918091435.465bfc1e.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.9.18.70621 Cc: freebsd-fs@freebsd.org Subject: Re: Fw: Linux/KDE and NFS locking on 7-stable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 07:14:38 -0000 On Thu, 17 Sep 2009 11:03:55 -0400 (EDT) Rick Macklem wrote about Re: Fw: Linux/KDE and NFS locking on 7-stable: RM> > I upgraded a FreeBSD fileserver last week from 7.0-stable to RM> > 7.2-stable and experience some weird problems now with Linux NFS RM> > clients. The Linux Clients mount their home directories via nfs. I RM> > usually use "nolock" on the client side, because file locking was RM> > always troublesome in the past. On the Clients the users run kde 3.5 RM> > or 4.2. After the update of the server kde 3.5 quit starting up RM> > (after logging in with kdm) on the spalsh screen and comes up with RM> > some kind of I/O error when writing to the home dir. At the same RM> > time the server complains about RM> > kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416 RM> I think this happens when the nlm in the server tries to contact the RM> client. ??? My NFS-Clients are accessing the server via a NAT router. There is no way the server could contact the clients. RM> I believe setting the following in the server's /etc/rc.conf RM> and rebooting the server (or just killing off lockd on the server), RM> combined with "nolock" as you have on the above Linux mount, might RM> work ok: RM> rpc_lockd_enable="NO" RM> rpc_statd_enable="NO" I did not try that so far, as there are some clients which seem to work fine with locking. RM> Imo, the nlm protocol was poorly designed and has always resulted in RM> interoperability problems. Although I fiddle with NFS, I avoid the NLM RM> like the plague:-) Seems so. Why would one want to have a server contact a client anyway? :-) Yesterday I played around with it some more, and have a solution now (at least I hope so :-) with combining "nolock" with "tcp" on the client side. I read some oder mails (from you?) here that stated problems with the new server and strange combinations of mounting via udp and accessing via tcp (although I did not look up what the Linux clients actually do). Before I had either no protocol setting for the clients or they were explicitely using udp (because that solved the problems I had with locking when I was still using 7.0-stable :-). RM> Good luck with it, rick RM> ps: If you need to run the lockd on the server, starting the lockd in RM> the Linux client might help, although I'd still use "nolock" on RM> the Linux mount. I think statd is running on the Linux client anyway. Will have to look for lockd. Thanks for the hints. I still wonder a bit why nfs/locking is often so much of a hassle. Shouldn't it be some kind of established standard technique after all the years? Not that I would want to use smb instead, but still... btw: are there any alternatives? cu Gerrit