From: Theo Markettos <nfs@markettos.org.uk>
Subject: Re: Multiple heterogeneous NFS servers on one machine
Date: Wed, 31 May 2006 12:42:55 +0100
Message-ID: <20060531114254.GE30710@chiark.greenend.org.uk>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: nfs@lists.sourceforge.net
In-Reply-To: <200605292315.23951.bernd-schubert@gmx.de>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

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.

Thanks
Theo


-------------------------------------------------------
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