Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2003 14:07:26 -0800
From:      Steve Sizemore <steve@ls.berkeley.edu>
To:        "Andrew P. Lentvorski, Jr." <bsder@allcaps.org>
Cc:        Dan Nelson <dnelson@allantgroup.com>, current@FreeBSD.ORG
Subject:   Re: NFS file unlocking problem
Message-ID:  <20030317220726.GC51736@math.berkeley.edu>
In-Reply-To: <Pine.LNX.4.44.0303171255310.15683-100000@mail.allcaps.org>
References:  <20030317060018.GA45288@math.berkeley.edu> <Pine.LNX.4.44.0303171255310.15683-100000@mail.allcaps.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 17, 2003 at 01:21:19PM -0800, Andrew P. Lentvorski, Jr. wrote:
> On Sun, 16 Mar 2003, Steve Sizemore wrote:
> 
> The dump doesn't seem to be attached.  However, I note that the request

It appears that there are problems sending the raw dump. I've tried
twice - once 2 minutes after I sent the original message, and once
again when I got this from you. Neither has shown up on the list.
I can find another way to make it available if you need to see it.

> being sent is SETLKW which is a blocking wait until lock is granted.  If
> the server thinks the file is already locked, it will hang *and* that is 
> the proper behavior.
> 
> What is the result of running this locally on the NFS server and 
> attempting to lock the underlying file?  If rpc.lockd is hanging onto a 
> lock, running that perl script locally on the actual file (not an NFS 
> mounted image of it) should also hang.

It seems to work as expected (at least as I expect) on the server. If
no other process has a lock, then the program locks the file, unlocks
it, and exits immediately. If the remote client is trying to
lock/unlock the file, then running the same program on the server also
hangs.

One other twist - recently, the behavior is less predictable. A couple
of times in the last 24 hours, the lock/unlock on the client has
actually worked as it should. The first time it happened, I was so
surprised, that I thought I must have locked a local file rather than
an NFS mounted file. On other occasions, the program has succeeded
after very long hangs, .e.g

	% time plock xxx
	Locking xxx
	Unlocking xxx

	Done
	0.21u 0.05s 55:35.33 0.0%

This makes me wonder whether waiting indefinitely would succeed in all
cases. (Note, however, that I've frequently waited more than an hour
before killing the process or giving up.)

> As a side note, you probably want to create a C executable to do this kind
> of fcntl fiddling when attempting to test NFS.  That way you can use a
> locally mounted binary and you won't wind up with all of the Perl access
> calls on the NFS wire.  Or, at least, use a local copy of Perl.

If I trusted my C skills as much as I trust my perl skills, I would do
that. The perl stuff is all mounted locally, so there shouldn't be any
perl nfs traffic on the wire.

Let me know if you still need to see the dump.

Steve
-- 
Steve Sizemore <steve@ls.berkeley.edu>, (510) 642-8570
Unix System Manager
    Dept. of Mathematics and College of Letters and Science
    University of California, Berkeley

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030317220726.GC51736>