From: Tom Tucker <tom@opengridcomputing.com>
Subject: Re: [RFC,
	PATCH 0/3] svc: gnb review cleanup for transport switch
Date: Fri, 12 Oct 2007 11:27:42 -0500
Message-ID: <1192206462.30080.28.camel@trinity.ogc.int>
References: <20071011022356.3501.63859.stgit@dell3.ogc.int>
	<20071011203029.GE22823@fieldses.org>
	<1192140282.7491.33.camel@trinity.ogc.int>
	<20071011220820.GF22823@fieldses.org>
	<1192202234.30080.21.camel@trinity.ogc.int>
	<20071012154124.GB1025@fieldses.org>
Reply-To: tom@opengridcomputing.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: neilb@suse.de, nfs@lists.sourceforge.net, gnb@sgi.com
To: "J. Bruce Fields" <bfields@fieldses.org>
In-Reply-To: <20071012154124.GB1025@fieldses.org>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net


We'll I've come full circle. The bad ip address that was causing the
callback to fail was coming from the client. If I do the mount as
follows:

# mount -t nfs4 -o clientaddr=<correct_addresss> nfssrv:/ /pnfs

Everything works fine and Connectathon runs as expected. I don't know
what the deal is with the mount command, but I'm not using the latest
and greatest for sure.

Can you do me a huge favor and see if you get the same behavior on your
end?  

I did find a few things to clean up, but it works for me with or without
the cleanup. I'll post the clean ups shortly.

Tom

On Fri, 2007-10-12 at 11:41 -0400, J. Bruce Fields wrote:
> On Fri, Oct 12, 2007 at 10:17:14AM -0500, Tom Tucker wrote:
> > On Thu, 2007-10-11 at 18:08 -0400, J. Bruce Fields wrote:
> > > On Thu, Oct 11, 2007 at 05:04:42PM -0500, Tom Tucker wrote:
> > > > I think I found the problem. The patchset is not caching the auth data
> > > > properly. This causes the server to fail the setting of the client id
> > > > with a 10018 error.
> > > > 
> > > > I'll send a patch off tonight....sorry :-\
> > 
> > A quick update. The problem is not what I thought it was, but I did
> > discover some interesting things:
> > 
> > - If you wait 60 seconds after the nfs4 mount, everything works fine.
> > You can run connectathon and the world is happy. Before the 60 seconds
> > you get the hang. Curiously, there are connection management timers in
> > the client that have this value.
> 
> Oh, well that may be just the grace period--we don't generally allow any
> opens for the first lease time (45 seconds by default, I think?)
> 
> (We should be smarter and skip the grace period in cases where we know
> no former clients held state on the server.  I'm hoping that'll be fixed
> in the next month.)
> 
> > - It looks like the module load logic that is down in the
> > crypto_alloc_hash path is not working properly. Maybe the module name
> > changed or something, or maybe it always worked this way and I'm
> > confused, but you have to manually load md5 for nfs4 to work
> > 
> > - It looks like the callback path is still broken. It's not the port
> > number, it's the IP address. Since I moved the IP address, it's likely
> > that I'm the culprit. 
> 
> OK, thanks.
> 
> --b.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs