Re: NFS server broken for -current

Dan Nelson schrieb:
> 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

You are right. Seems I didn't read carefully enough.

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

Absolutely not. Now swap in use. No running userland process. Nothing.

And like I said this problem only occurs with past 5.1 so I don't think 
debugging the linux box would help.
How can I find out what the FreeBSD kernel really does when it claims to 
use 44% Sys and writes to disk?
The LED on from my 3ware controller also flashes so there _is_ data 
written (or read?) but not from NFS over the wire.

Very strange to me

Thanks,

-Harry