On 6 Apr 2008, at 07:38, Tz-Huan Huang wrote:
On Sun, Apr 6, 2008 at 2:05 PM, Rong-en Fan <[EMAIL PROTECTED]> wrote:
On Sun, Apr 6, 2008 at 1:18 PM, Tz-Huan Huang <[EMAIL PROTECTED]>
wrote:
Hi,
Thanks for your suggestion, but we don't accept this workaround.
After doing binary searching, I find that this commit break the
working lockd:
http://lists.freebsd.org/pipermail/cvs-src/2008-March/089037.html
I have rolled back the lockd.c to 1.20 in our nfs server and it
works
fine as before.
Add dfr@ to CC list.
I'm curious about this change, could you check what socket bind by
rpc.lockd and rpc.statd before and after lockd. rev 1.21+1.22
changes?
Ok, following is the output of sockstat -4l :
Before the changes:
daemon rpc.lockd 83002 3 udp4 *:677 *:*
daemon rpc.lockd 83002 4 tcp4 *:946 *:*
daemon rpc.lockd 83002 7 udp4 *:642 *:*
root rpc.lockd 83001 3 udp4 *:677 *:*
root rpc.lockd 83001 4 tcp4 *:946 *:*
root rpc.lockd 83001 7 udp4 *:642 *:*
root rpc.statd 973 3 udp4 *:964 *:*
root rpc.statd 973 4 tcp4 *:602 *:*
After the changes:
(with -h 140.112.29.133)
daemon rpc.lockd 82817 4 udp4 127.0.0.1:696 *:*
daemon rpc.lockd 82817 5 udp4 140.112.29.133:696 *:*
daemon rpc.lockd 82817 6 tcp4 127.0.0.1:696 *:*
daemon rpc.lockd 82817 7 tcp4 140.112.29.133:696 *:*
daemon rpc.lockd 82817 9 udp4 *:974 *:*
root rpc.lockd 82816 4 udp4 127.0.0.1:696 *:*
root rpc.lockd 82816 5 udp4 140.112.29.133:696 *:*
root rpc.lockd 82816 6 tcp4 127.0.0.1:696 *:*
root rpc.lockd 82816 7 tcp4 140.112.29.133:696 *:*
root rpc.lockd 82816 9 udp4 *:974 *:*
root rpc.statd 973 3 udp4 *:964 *:*
root rpc.statd 973 4 tcp4 *:602 *:*
(without -h 140.112.29.133)
daemon rpc.lockd 82541 4 udp4 *:915 *:*
daemon rpc.lockd 82541 5 tcp4 *:915 *:*
daemon rpc.lockd 82541 7 udp4 *:713 *:*
root rpc.lockd 82540 4 udp4 *:915 *:*
root rpc.lockd 82540 5 tcp4 *:915 *:*
root rpc.lockd 82540 7 udp4 *:713 *:*
root rpc.statd 973 3 udp4 *:964 *:*
root rpc.statd 973 4 tcp4 *:602 *:*
More information would be provided if necessary.
It would be useful to get a packet trace from tcpdump (e.g. tcpdump -w
<file>) that shows what happens on the wire when the linux client
fails to lock a file on the freebsd server.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
