--GvXjxJ+pjyke8COw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu 23 Jan 2003 at 13:21:30 -0500, Thor Lancelot Simon wrote:
> For my own part, I'm chasing some kind of _nasty_ NQNFS problem
> that happens with NetBSD clients on a NetBSD server (all -current
> as of a week or two ago).  

Did you read my mail of 10 january about "NFS -q questions"? It's about
1.6 release, but it may be related.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert - rhialto@       -- Woe betide the one who feels
\X/ polderland.nl  -- remorse without sin - Tom Poes, "Het boze oog", 4444.

--GvXjxJ+pjyke8COw
Content-Type: message/rfc822
Content-Disposition: inline

	by polderland.nl (8.11.6+3.4W/8.11.3) id h0AJaPD18235;
	Fri, 10 Jan 2003 20:36:25 +0100 (CET)
Date: Fri, 10 Jan 2003 20:36:25 +0100
From: Olaf Seibert <rhialto@polderland.nl>
To: current-users@netbsd.org
Subject: NFS -q questions ..
Message-ID: <20030110203625.A17665@polderland.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i

I am mounting NFS-mounting some volumes using the -q option (NQNFS), and
I noted that if I try to access a file from the client that is in use on
the server, the client stalls in "vnlock". First I was kind-of expecting
that the client would continue once the server had finished with the
file, but no such luck. In fact, a ls -l on the directory which
contained the file also stalled. I did not try if this was a beginning
of a "race-to-root" but I expect so. On the server side, nothing unusual
was to be noticed.

An attempted reboot of the client never finished; even though the
message "syncing filesystems..." appeared, after a forced power off/on
they were considered dirty and fsck went on to check them.

Is this to be expected?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert - rhialto@       -- Woe betide the one who feels
\X/ polderland.nl  -- remorse without sin - Tom Poes, "Het boze oog", 4444.

--GvXjxJ+pjyke8COw--