From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: Multiple heterogeneous NFS servers on one machine
Date: Wed, 31 May 2006 15:09:48 -0400
Message-ID: <1149102588.32074.21.camel@lade.trondhjem.org>
References: <20060529182400.GQ13353@chiark.greenend.org.uk>
	 <200605292136.16422.bernd-schubert@gmx.de>
	 <20060529204252.GD30710@chiark.greenend.org.uk>
	 <200605292315.23951.bernd-schubert@gmx.de>
	 <20060531114254.GE30710@chiark.greenend.org.uk>
Mime-Version: 1.0
Content-Type: text/plain
Cc: nfs@lists.sourceforge.net
To: Theo Markettos <nfs@markettos.org.uk>
In-Reply-To: <20060531114254.GE30710@chiark.greenend.org.uk>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

On Wed, 2006-05-31 at 12:42 +0100, Theo Markettos wrote:
> On Mon, May 29, 2006 at 11:15:23PM +0200, Bernd Schubert wrote:
> > >
> > Can you add mountvers=3,nolock as described in my howto? 
> 
> Ah, thanks.  That succeeds instantly.
> 
> > > If I try to connect from the NFS client on my RISC OS machine it says "NFS
> > > call failed (Operation is not supported)" which looking at the source means
> > > it's got a code 10004, NFSERR_NOTSUPP, from the RPC mechanism.  That's with
> > > it in NFS 3 mode - in NFS 2 mode it just says "Unknown error" which, when I
> > > make it output the number, is 22.  I have the source for this client so  I
> > > can make it output more information if you can suggest what would be of
> > > help.
> > 
> > An ethereal capture (and the sources ) would be helpfull in that case. My nfs 
> > protocol knowlegde got a bit rosty, but I need to refresh it anyway to finish 
> > my pending patches for unfs3 (if I only had the time to write them :(  )
> 
> OK, Ethereal capture can be found at:
> http://www.harbinge.com/temp/nfs-ethereal.libpcap (raw dump file)
> http://www.harbinge.com/temp/nfs-ethereal.txt (text explanation)
> 
> Briefly, the client is 172.21.115.2 (iapetus) and the server 172.21.115.12
> (ordovician).  There a bit of random ARP and broadcast traffic in there too
> that I didn't manage to filter out.  Both NFS and MOUNT were listening on
> port 1599.
> 
> Source is in:
> http://www.harbinge.com/temp/sunfish-108.zip
> 
> For historical reasons files are named c/foo rather than foo.c.  Much of the
> RPC code is generated by perl script ProcessSpec from XDR specifications
> (see makefile) - I've put the output .c and .h files in the archive so it's
> easier for you to poke around.  Function names in caps are usually RPC calls.
> 
> The code that initiates the connection is func_newimage() in
> imageentry_newimage.c.  This then calls
> imageentry_func.c/func_newimage_mount() that calls MOUNT.
> 
> Another entry point I think then calls imageentry_func.c/func_readdirinfo()
> that calls imageentry_common.c/filename_to_finfo() which fires off some
> LOOKUP commands.  Then back in func_readdirinfo() we call READDIRPLUS which
> gives up back error 10004.
> 
> Aha, right.  It seems unfs3 doesn't support READDIRPLUS.  I'll see if the
> client can be modified to call READDIR only.

_IF_ unfs3 is returning the correct error when we call READDIRPLUS (i.e.
NFS3ERR_NOTSUP == 10004), then the client will already automatically
fall back to using READDIR only.

  Trond


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs