| So Irix is the client, Linus is the server.....
| Let me clarify some things. Nfs v2 does not support lockd/statd, i.e.
| file locking, as far as I know, only nfs v3 does. I am not sure why
| Irix is sending any type of lockd requests in the case of using nfs v2.
| I need to check on this. Can you send me a snoop/netsnoop of the
| problem, i.e. when Irix 6.5 client attaempts to send a lock request to
| the Linus nfs server? Make sure that the snoop is very verbose so I can
| see all the fields of all the packets.
| A sample test case and what I would need is:
| 1-/etc/mount (output for the mounted nfs v2 filesystem on Irix 6.5.1)
| 2-snoop/netsnoop before/during/after a test program that runs file
| locking and shows the 64 bit cookie, etc.)
| 3-unmount/remount using nfs v3 (vers=3) if the Linux system support nfs
| v3. If mounted via nfs v3, repeat steps 1 and 2 above for me and send
| me info.
Well! I was sure surprised to hear that lockd doesn't work for
NFS v2! I haven't performed all the snooping yet because I have other
problems to deal with. It appears that the top 4 bits of the cookie can
be ignored. Here is the section from the man pages:
32bitclients
Causes the server to mask off the high order 32 bits of
directory cookies in NFS version 3 directory operations. This
option may be required when clients run 32-bit operating
systems that assume the entire cookie is contained in 32 bits
and reject responses containing version 3 cookies with high
bits on. IRIX 5.3 and Solaris 2.5 are examples of 32-bit
operating systems with this behavior, which produces error
messages like "Cannot decode response" on directory operations.
XFS filesystems on the server can generate cookies with high
bits on. Exporting filesystems with the 32bitclients option
causes these bits to be masked and prevents error messages.
If I had a nice test server I would add code for ignoring the top 4 bits.
The needed changes are here:
fs/lockd/xdr.c:
---------------
/*
* XDR functions for basic NLM types
*/
static inline u32 *
nlm_decode_cookie(u32 *p, u32 *c)
{
unsigned int len;
if ((len = ntohl(*p++)) == 4) {
*c = ntohl(*p++);
} else if (len == 0) { /* hockeypux brain damage */
*c = 0;
} else {
printk(KERN_NOTICE
"lockd: bad cookie size %d (should be 4)\n", len);
return NULL;
}
return p;
}
Although Alan Cox was looking at implimenting NFS v3. I haven't
heard any reports from it, but if that works even a little, our problems
are solved. :^)
On Mon, 9 Nov 1998, Joern Lammers wrote:
> I saw the same problem using Linux 2.1.125 with knfsd-981010. SGI and
> AIX machines do NFS mounts on the Linux box and the software running on
> those machines uses file locking. Everything works fine for the AIXes
> but when I try to mount from the SGIs (NFSv2, no matter if Octane,O2 or
> Indigo2) the lockd on the Linux box denies locking, reporting a 'bad
> cookie size' of 8 instead of 4 bytes. The cookies are all treated as 4
> bytes long so modifying the cookie sizes in the header files doesn't do
> a thing. I ended up mounting with the option 'private' but that's no
> real solution. Please let me know if anyone solves this.
-Ben
------------------------------------ |\ _,,,--,,_ ,) ----------
Benjamin Kahn /,`.-'`' -, ;-;;'
(212) 924 - 2220 |,4- ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
Meet Linux: Forrest Gump as an operating system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/