Hello,
I have an nfs server who exports some backup directories for the lan's
users, it's a new install.
First I would like say that's not an hardware problem, because we have
no problem to use appletalk, ftp, ...
I can mount remotly a partition on the nfs server without problem but
when I copy something on it, the client ('cp' in this case) hangs, and I
receive these messages on my console :
nfs: task XXX can't get a request slot
where XXX is begin from 1 to...
When I look on the server, the file I was trying to copy is only 8192
bytes :
-rwxr-xr-x 1 root root 8192 May 13 16:56 bash
After looking web, newsgroup, etc.. I've tried all what I can do to
optimize performance (wsize=8192,rsize=8192,hard/soft, etc.. etc..)
The only changes is when I use wsize and rsize to 8192, the file I sent
to the server can goes to 16384 bytes, but never more..
This is a LAN of ~ 10 computers, 100mbps, and we use switchs.
The servers and workstation use Debian woody, nfs kernel and user server
tried, same results.
Any type of help is welcome.
Thanks.
--
Nicolas Brainez
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Nicolas Brainez <[email protected]> writes:
> Hello, I have an nfs server who exports some backup directories
> for the lan's users, it's a new install.
> First I would like say that's not an hardware problem, because
> we have no problem to use appletalk, ftp, ...
I'll bet you it is. Have you tried using a different network card + driver?
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2002-05-13 at 17:17, Trond Myklebust wrote:
> >>>>> " " == Nicolas Brainez <[email protected]> writes:
>
> > Hello, I have an nfs server who exports some backup directories
> > for the lan's users, it's a new install.
>
> > First I would like say that's not an hardware problem, because
> > we have no problem to use appletalk, ftp, ...
>
> I'll bet you it is. Have you tried using a different network card + driver?
Nope, I've not another network card, and i've absolutely no problem with
others protocols like appletalk and ftp, I can't believe it's an
hardware problem in these conditions.
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Make sure that your server and clients agree on the MTU of the network.
I don't recall having seen the request slot message associated with that
sort of problem, but an MTU problem can cause messages to be dropped.
Can you nfs-mount a partition exported from the server on the server
itself? If so, can you copy on the nfs-mounted partition? (Trying to
isolate the issue from the network)
David Ritch
On Mon, 2002-05-13 at 11:10, Nicolas Brainez wrote:
> Hello,
>
> I have an nfs server who exports some backup directories for the lan's
> users, it's a new install.
>
> First I would like say that's not an hardware problem, because we have
> no problem to use appletalk, ftp, ...
>
> I can mount remotly a partition on the nfs server without problem but
> when I copy something on it, the client ('cp' in this case) hangs, and I
> receive these messages on my console :
>
> nfs: task XXX can't get a request slot
>
> where XXX is begin from 1 to...
>
> When I look on the server, the file I was trying to copy is only 8192
> bytes :
>
> -rwxr-xr-x 1 root root 8192 May 13 16:56 bash
>
> After looking web, newsgroup, etc.. I've tried all what I can do to
> optimize performance (wsize=8192,rsize=8192,hard/soft, etc.. etc..)
>
> The only changes is when I use wsize and rsize to 8192, the file I sent
> to the server can goes to 16384 bytes, but never more..
>
> This is a LAN of ~ 10 computers, 100mbps, and we use switchs.
> The servers and workstation use Debian woody, nfs kernel and user server
> tried, same results.
>
> Any type of help is welcome.
>
> Thanks.
>
> --
> Nicolas Brainez
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: [email protected]
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, May 13, 2002 at 12:35:24PM -0400, David B. Ritch wrote:
> Make sure that your server and clients agree on the MTU of the network.
> I don't recall having seen the request slot message associated with that
> sort of problem, but an MTU problem can cause messages to be dropped.
Anything that causes packets to get discarded can cause the request
slot message. The MTU thing can be tested by pinging with 8192 byte
packets, which is also a good way to figure out if your network has
enough lossage to cause big UDP packets to be unlikely to arrive,
while short ones work fine. And other things that go bump in the
night.
greg
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
M=E5ndag 13. mai 2002 17:34 skreiv Nicolas Brainez:
> Nope, I've not another network card, and i've absolutely no problem wit=
h
> others protocols like appletalk and ftp, I can't believe it's an
> hardware problem in these conditions.
That is completely irrelevant. You are comparing apples and pears: TCP ca=
n be=20
made to run reliably over pigeons. NFS uses UDP, and usually presses the=20
cards and drivers to the limit.
Cheers,
Trond
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
OK, thanks for all your response!
I've tried the following:
- Change the NIC (old was rtl8139, new is AMD pcnet32): no changes
- Mount nfs in local: no problem
- Pinging server with 8192 bytes: high packet loss ! (between 30 & 90%)
It's maybe no more an nfs problem but, in my LAN the mtu are @ 1500 on
every machine, and there's no router between server and workstations,
some tips will be appreciated :-).
--
Nicolas Brainez
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, May 15, 2002 at 10:46:20AM +0200, Nicolas Brainez wrote:
> - Change the NIC (old was rtl8139, new is AMD pcnet32): no changes
The rtl8139 is a terrible NIC. It doesn't seem to work under high load
under any OS.
> - Pinging server with 8192 bytes: high packet loss ! (between 30 & 90%)
Well, there's your problem. As you could imagine, NFS with 8k packets
won't work so well, but you won't notice for telnet.
You have 2 choices to cover up the problem:
1) Use NFS over TCP.
2) Use NFS with UDP and 1k packets.
As for what the underlying problem is, I don't really know. I would
follow up by using "netperf" or another TCP-related test to see if the
TCP bandwidth is acceptable. If it is, then you can not fix it...
greg
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs