Re: NFS server broken for -current

In the last episode (Feb 17), Harald Schmalzbauer said:
> Kris Kennaway schrieb:
> >On Tue, Feb 17, 2004 at 04:30:26AM +0100, Harald Schmalzbauer wrote:
> >>some weeks ago I found that when connecting from a linux client to
> >>-a current NFS server the connection "locks" up. Now I have decided
> >>to try again and I have a new box where I can do tests. This
> >>problem still exists for -current from 14.Feb.
> >>
> >>I saw that systat -vm still shows disk traffic (about 7Mb/s) while
> >>em0 (my NIC) only reports 5 interrupts. There's no traffic on the
> >>wire but disk is writing? (I'm sure there's no other process which
> >>could cause disk usage!) Also Sys usage is reported to be 44%!
> >>
> >>Let me know how I can help. NFS really should work again asap.
> >
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56461
> 
> Oh, _very_ interesting.
> 
> Does only FreeBSD > 5.1 use 16-byte cookies? I have a 4.9 box which 
> works fine with Linux and if I remember correctly 5.1 also haven't had 
> this incompatibility.

4.x clients don't do locking at all.  Lock requests always return
success without checking with the server.  4.x servers do handle client
locks, though.

I don't think kern/56461 should get committed; the bug is in the Linux
kernel, and should be fixed there.  At the very least the Linux kernel
should reject the locking request instead of simply dropping it.

Anyhow, none of that applies to you; it only affects a FreeBSD client
trying to lock a file on a Linux server.  You're going the other way
around, right?  I'd say run strace on the Linux program and find out
what syscall it's hanging on, and run tcpdump or tethereal to determine
whether it's really an NFS request that's failing.
 
> But what about that mystiq disk access? It's not so funny to see my
> 3ware controler (the LED) accessing disks while no process is running
> (shown) which would cause it.

Swapping?

-- 
	Dan Nelson
	dnelson_at_allantgroup.com