Re: NFS server broken for -current

• Previous message: Stefan Ehmann: "Re: PANIC: trap.c"
• In reply to: Dan Nelson: "Re: NFS server broken for -current"
• Next in thread: Kris Kennaway: "Re: NFS server broken for -current"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 17 Feb 2004 20:36:57 +0100
To: Dan Nelson <dnelson@allantgroup.com>

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

• application/pgp-signature attachment: OpenPGP digital signature

• Previous message: Stefan Ehmann: "Re: PANIC: trap.c"
• In reply to: Dan Nelson: "Re: NFS server broken for -current"
• Next in thread: Kris Kennaway: "Re: NFS server broken for -current"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]