From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 07:15:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27ECF16A4CF for ; Thu, 26 Feb 2004 07:15:00 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A123643D41 for ; Thu, 26 Feb 2004 07:14:57 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i1QFDxDL091882; Thu, 26 Feb 2004 10:13:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i1QFDxWv091879; Thu, 26 Feb 2004 10:13:59 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 26 Feb 2004 10:13:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Rob Heise (rheise)" In-Reply-To: <000c01c3fc1d$15097ba0$0b8f530a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: SunOS 5.8 NFS server mounted by linux 2.4.20 client Locking problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 15:15:00 -0000 On Wed, 25 Feb 2004, Rob Heise (rheise) wrote: > Any one have a good idea whats going on here: > > open("/usr/SD/tibco/jms/3.1.2/bin/datastore/meta.db", > O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 7 > fcntl64(7, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, > 0xbfffe550) = -1 ENOLCK (No locks available) > close(7) = 0 > > rpc.lockd and statd are running. Well, Solaris generally returns ENOLCK from fcntl() when you exceed a resource limit on the number of locks permitted on a single file or region. However, it looks like you truss is on the client, so it would be interesting to see what the NFS server returns to the client on the wire. This isn't really the pervue of the FreeBSD mailing lists, but I've found a combination of tcpdump and ethereal to be an ideal NFS debugging tool: ethereal can provide detailed decoding of NFS RPCs that are invaluable in figuring out what's actually going on, despite what the client may say is happening. Remember that the NFS client will often interpose its own limits, translations of error numbers, etc, in ways that can be misleading... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research