Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Apr 2003 14:54:31 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        omestre@freeshell.org
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: rpc.lockd
Message-ID:  <20030429195431.GA22259@dan.emsphone.com>
In-Reply-To: <20030429160500.E514F107C1@ws-tor-0004.procergs>
References:  <20030429160500.E514F107C1@ws-tor-0004.procergs>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Apr 29), omestre@freeshell.org said:
>  I'm having problems with rpc.lockd (nfs locks)...
>  Now, i guess that i know "where is" the problem. I have one Linux box
> as my NFS server to Linux and FreBSD 4.x machines, working fine.
>  I have some FreeBSD 5.0 machines that do not work the locks. Looking at
> the log in the Linux server, i have saw these messages:
> kernel: lockd: bad cookie size 16 (only cookies under 8 bytes are supported.)
>  Without 5.0 clients, these messages go out! So, how can i make the rpc.lockd
> work like 4.x series? 
>  The 5.0 lock protocol, i guess, is incompatible with linux ( kernel 2.4.20).
>  Thanks.  

FreeBSD 4.* didn't do locking at all; rpc.lockd simply accepted all
requests but never tried to lock the remote sfile.

FreeBSD 5's rpc.lockd does send lock requests, but the Linux kernel
apparently cannot handle the 16-byte request.

If you were happy with FreeBSD 4's behaviour, try just not running
rpc.lockd on your FreeBSD 5 systems.

If you really need locking, you can probably cut FreeBSD's cookie size
down to 8 bytes by removing the pid_start element from struct
lockd_msg_ident in /sys/nfsclient/nfs_lock.h (and removing the code
that sets it in nfs_lock.c), and rebuilding world and the kernel.  A
better solution would be to submit a bugreport to your Linux vendor and
have them fix it on their end.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030429195431.GA22259>