xfs
[Top] [All Lists]

Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops

To: linux-xfs@xxxxxxxxxxx
Subject: Re: 2.4.18 XFS 1.1 : Gave up on XFS - too many Oops
From: Christian Guggenberger <christian.guggenberger@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 24 Jul 2002 20:34:41 +0200
In-reply-to: <20020724203318.C791@xxxxxxxxxxxxxxxxxxxxxxxx>; from christian.guggenberger@xxxxxxxxxxxxxxxxxxxxxxxx on Wed, Jul 24, 2002 at 20:33:18 +0200
References: <Pine.GSO.4.10.10207240849290.4211-100000@xxxxxxxxxxxxxxxxx> <20020724192706.A17637@xxxxxxxxxxxxx> <20020724203318.C791@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On 24 Jul 2002 19:27:06 Andi Kleen wrote:
>      Initially I used the SGI XFS ISO (RH7.1 I think) to set
> the system up.  The system ran OK except for frequent rpc timeout
> problems reported by the NFS clients but only during write operations.
> The problem could be made to happen by setting processes running on
> each client which wrote data to the NFS server at the fastest rate
> possible, i.e.:
>
>     dd  if=/dev/zero  count=<bignumber>  bs=<various>  of=/big/file

[...]

A common problem with many older linux kernels is that NFS is using a 64K
socket buffer only. This can cause packets to get dropped when the buffer
queue is overloaded on the NFS server. What you can do is to increase
/proc/sys/net/core/[rw]mem_{default,max}. This has to be done before the
kernel nfs server is initialized, e.g. in the NFS server start script
before the daemons are started.
Newer kernels should do the tuning automatically. Same can be done on
the clients.
...

we are planning to integrate a gigabit interface (intel e1000) in our fileserver (NFS) soon.
Could one of you point out some kernel (proc) tunings i should do ?
Or should the default settings work fine (and performant) ?

Christian


<Prev in Thread] Current Thread [Next in Thread>