Linux NFS development
 help / color / mirror / Atom feed
* RE: Linux client network performance
@ 2003-06-25 19:40 Lever, Charles
  2003-06-26 16:50 ` s o f i a
  2003-06-27  9:29 ` Matthias Kittner
  0 siblings, 2 replies; 8+ messages in thread
From: Lever, Charles @ 2003-06-25 19:40 UTC (permalink / raw)
  To: s o f i a; +Cc: nfs, Matthias Kittner

hi sofia-

> Can you please let me know:
> - are there any identified workarounds?

yes, there are several.

1.  use NFS/TCP

2.  if you can't use NFS/TCP, upgrade your clients
    to 2.4.20 or later

3.  if you can't upgrade your clients, ensure the
    default socket buffer size on your clients is
    large before mounting any NFS servers (see
    below).

> - are there any papers or writeups on
> various other symptoms of this issue?

  http://www.netapp/com/tech_library/3183.html

contains instructions for deploying workarounds
in the appendix, including the socket buffer
enlargement workaround.

the symptoms that i described to valery are
what you should look for.  other behaviors
could be the result of many different problems.

> At one site, the customer environment mentioned
> about having issues with Linux clients; they
> had to change NFS block size to 8k....=20

reducing r/wsize helps, but is not a guaranteed
workaround.

> Wondering if one can comment about this one case,=20
> I noticed even with the Linux client side
> mounted at 8k, at a certain point in time,
> with a certain application that is write intensive,
> to a Solaris NFS server, the client had to do
> (2) writes, before the NFS server replied ...
> (in looking at the snoop) ... i am not sure, but
> i think the application had the capability to
> write in even less the 8k blocksize, and it seems
> like this eliminated the problem of NFS-writes
> from the linux client...=20

that's not a very clear description of the problem.
it sounds like your client is retransmitting NFS
write operations, but there isn't enough in your
description to determine why that might occur.

> > Sent: Wednesday, June 25, 2003 10:40 AM
> > To: Brasseur Val=E9ry
> > Cc: nfs@lists.sourceforge.net; Matthias Kittner
> > Subject: RE: [NFS] Linux client network performance
> >=20
> >=20
> > hi valery-
> >=20
> > > what's the "IP fragmentation bug" ?
> >=20
> > the Linux IP layer sends packet fragments on the
> wire
> > as it fragments each datagram.  it can run out of
> socket
> > buffer space in the middle of fragmenting a
> datagram.
> > the bug is that if it runs out of buffer space, it
> > stops fragmenting and drops the packet.  =20
> >=20
> > this leaves the receiving end with a bunch of
> fragments
> > it can't assemble into a whole datagram.  this
> becomes
> > a problem when the sending end is perpetually
> running
> > out of socket space.  this fills the receiving end's
> > reassembly queue with fragments that can't be used,
> > preventing all UDP traffic from getting to the
> server.
> >=20
> > the fix is to have it continue fragmenting this
> datagram
> > even though the socket buffer is "full."
> >=20
> > > what are the symptoms of this bug ?
> >=20
> > you're using NFS/UDP with largish r/wsize.  your
> > network features links of different speed (100Mb
> > mixed with GbE) between client and server, or is
> > routed rather than only switched.
> >=20
> > you see lots of IP fragments on your network from
> > one or two NFS clients.  you have periods of very
> slow
> > server and network performance, followed by periods
> of
> > normal performance. =20
> >=20
> > > > -----Original Message-----
> > > > From: Lever, Charles
> [mailto:Charles.Lever@netapp.com]
> > > > Sent: Wednesday, June 25, 2003 4:30 PM
> > > > To: Matthias Kittner
> > > > Cc: nfs@lists.sourceforge.net
> > > > Subject: RE: [NFS] Linux client network
> performance
> > > >=20
> > > >=20
> > > > hi matthias-
> > > >=20
> > > > it sounds like you've hit the IP fragmentation
> bug.
> > > > you should use NFS/TCP (the "tcp" mount option).
> > > >=20
> > > > probably it's your 2.4.19-based client that is
> > > > causing this problem.
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Matthias Kittner
> [mailto:kittner@vrcom.de]
> > > > > Sent: Wednesday, June 25, 2003 4:57 AM
> > > > > To: nfs@lists.sourceforge.net
> > > > > Subject: [NFS] Linux client network
> performance
> > > > >=20
> > > > >=20
> > > > > [I am not a subscriber, please CC to my
> eMail!]
> > > > >=20
> > > > > Hello,
> > > > >=20
> > > > > we have the following problem:
> > > > >=20
> > > > > - 2 linux clients:
> > > > > 	2.4.19-16mdk
> > > > > 	2.4.20
> > > > > - Solaris NFS-Server (nfs.server 1.21)
> > > > > 	SunOS 5.7
> > > > >=20
> > > > > If we compile on one of the linux machines
> sometimes in
> > > > this compile
> > > > > process the whole network hangs resp. is so
> slow that one
> > > can wait
> > > > > between 10s or 2min to finish a "ls".
> > > > >=20
> > > > > "snoop" at the nfs-server machine show
> very/very much "UDP
> > > > > continuation"=20
> > > > > traffic between the linux client and the
> solaris server.=20
> > > > Killing the
> > > > > compile process stops this messages.
> > > > >=20
> > > > > Can anyone help us? Is this a configuration
> problem or a bug?
> > > > >=20
> > > > > Regards,
> > > > > Matthias
> > > > >=20
> > > > >=20
> > > > >=20
> > > > >
> -------------------------------------------------------
> > > > > This SF.Net email is sponsored by: INetU
> > > > > Attention Web Developers & Consultants: Become
> An INetU
> > > > > Hosting Partner.
> > > > > Refer Dedicated Servers. We Manage Them. You
> Get 10% Monthly=20
> > > > > Commission!
> > > > > INetU Dedicated Managed Hosting=20
> > > http://www.inetu.net/partner/index.php
> > > > _______________________________________________
> > > > NFS maillist  -  NFS@lists.sourceforge.net=20
> > > > https://lists.sourceforge.net/lists/listinfo/nfs
> > > >=20
> > >=20
> > >=20
> > >
> -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An
> INetU
> > > Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get
> 10% Monthly=20
> > > Commission!
> > > INetU Dedicated Managed Hosting=20
> > http://www.inetu.net/partner/index.php
>=20
>=20
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU=20
> Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: Linux client network performance
@ 2003-06-25 18:09 s o f i a
  0 siblings, 0 replies; 8+ messages in thread
From: s o f i a @ 2003-06-25 18:09 UTC (permalink / raw)
  To: nfs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 5452 bytes --]

Hello,

(pls cc me, a colleague just forwarded
this to me...)

I have seen this at a customer site.
And thank you so much for the clarification.

Can you please let me know:
- are there any identified workarounds?
- are there any papers or writeups on
various other symptoms of this issue?

At one site, the customer environment mentioned
about having issues with Linux clients; they
had to change NFS block size to 8k.... 

Wondering if one can comment about this one case, 
I noticed even with the Linux client side
mounted at 8k, at a certain point in time,
with a certain application that is write intensive,
to a Solaris NFS server, the client had to do
(2) writes, before the NFS server replied ...
(in looking at the snoop) ... i am not sure, but
i think the application had the capability to
write in even less the 8k blocksize, and it seems
like this eliminated the problem of NFS-writes
from the linux client... 

any thoughts on this issue?

thanks in advance,

sofia.


> Sent: Wednesday, June 25, 2003 10:40 AM
> To: Brasseur Valéry
> Cc: nfs@lists.sourceforge.net; Matthias Kittner
> Subject: RE: [NFS] Linux client network performance
> 
> 
> hi valery-
> 
> > what's the "IP fragmentation bug" ?
> 
> the Linux IP layer sends packet fragments on the
wire
> as it fragments each datagram.  it can run out of
socket
> buffer space in the middle of fragmenting a
datagram.
> the bug is that if it runs out of buffer space, it
> stops fragmenting and drops the packet.   
> 
> this leaves the receiving end with a bunch of
fragments
> it can't assemble into a whole datagram.  this
becomes
> a problem when the sending end is perpetually
running
> out of socket space.  this fills the receiving end's
> reassembly queue with fragments that can't be used,
> preventing all UDP traffic from getting to the
server.
> 
> the fix is to have it continue fragmenting this
datagram
> even though the socket buffer is "full."
> 
> > what are the symptoms of this bug ?
> 
> you're using NFS/UDP with largish r/wsize.  your
> network features links of different speed (100Mb
> mixed with GbE) between client and server, or is
> routed rather than only switched.
> 
> you see lots of IP fragments on your network from
> one or two NFS clients.  you have periods of very
slow
> server and network performance, followed by periods
of
> normal performance.  
> 
> > > -----Original Message-----
> > > From: Lever, Charles
[mailto:Charles.Lever@netapp.com]
> > > Sent: Wednesday, June 25, 2003 4:30 PM
> > > To: Matthias Kittner
> > > Cc: nfs@lists.sourceforge.net
> > > Subject: RE: [NFS] Linux client network
performance
> > > 
> > > 
> > > hi matthias-
> > > 
> > > it sounds like you've hit the IP fragmentation
bug.
> > > you should use NFS/TCP (the "tcp" mount option).
> > > 
> > > probably it's your 2.4.19-based client that is
> > > causing this problem.
> > > 
> > > > -----Original Message-----
> > > > From: Matthias Kittner
[mailto:kittner@vrcom.de]
> > > > Sent: Wednesday, June 25, 2003 4:57 AM
> > > > To: nfs@lists.sourceforge.net
> > > > Subject: [NFS] Linux client network
performance
> > > > 
> > > > 
> > > > [I am not a subscriber, please CC to my
eMail!]
> > > > 
> > > > Hello,
> > > > 
> > > > we have the following problem:
> > > > 
> > > > - 2 linux clients:
> > > > 	2.4.19-16mdk
> > > > 	2.4.20
> > > > - Solaris NFS-Server (nfs.server 1.21)
> > > > 	SunOS 5.7
> > > > 
> > > > If we compile on one of the linux machines
sometimes in
> > > this compile
> > > > process the whole network hangs resp. is so
slow that one
> > can wait
> > > > between 10s or 2min to finish a "ls".
> > > > 
> > > > "snoop" at the nfs-server machine show
very/very much "UDP
> > > > continuation" 
> > > > traffic between the linux client and the
solaris server. 
> > > Killing the
> > > > compile process stops this messages.
> > > > 
> > > > Can anyone help us? Is this a configuration
problem or a bug?
> > > > 
> > > > Regards,
> > > > Matthias
> > > > 
> > > > 
> > > > 
> > > >
-------------------------------------------------------
> > > > This SF.Net email is sponsored by: INetU
> > > > Attention Web Developers & Consultants: Become
An INetU
> > > > Hosting Partner.
> > > > Refer Dedicated Servers. We Manage Them. You
Get 10% Monthly 
> > > > Commission!
> > > > INetU Dedicated Managed Hosting 
> > http://www.inetu.net/partner/index.php
> > > _______________________________________________
> > > NFS maillist  -  NFS@lists.sourceforge.net 
> > > https://lists.sourceforge.net/lists/listinfo/nfs
> > > 
> > 
> > 
> >
-------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An
INetU
> > Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get
10% Monthly 
> > Commission!
> > INetU Dedicated Managed Hosting 
> http://www.inetu.net/partner/index.php


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: Linux client network performance
@ 2003-06-25 17:39 Lever, Charles
  0 siblings, 0 replies; 8+ messages in thread
From: Lever, Charles @ 2003-06-25 17:39 UTC (permalink / raw)
  To: Brasseur Valéry; +Cc: nfs, Matthias Kittner

hi valery-

> what's the "IP fragmentation bug" ?

the Linux IP layer sends packet fragments on the wire
as it fragments each datagram.  it can run out of socket
buffer space in the middle of fragmenting a datagram.
the bug is that if it runs out of buffer space, it
stops fragmenting and drops the packet.  =20

this leaves the receiving end with a bunch of fragments
it can't assemble into a whole datagram.  this becomes
a problem when the sending end is perpetually running
out of socket space.  this fills the receiving end's
reassembly queue with fragments that can't be used,
preventing all UDP traffic from getting to the server.

the fix is to have it continue fragmenting this datagram
even though the socket buffer is "full."

> what are the symptoms of this bug ?

you're using NFS/UDP with largish r/wsize.  your
network features links of different speed (100Mb
mixed with GbE) between client and server, or is
routed rather than only switched.

you see lots of IP fragments on your network from
one or two NFS clients.  you have periods of very slow
server and network performance, followed by periods of
normal performance. =20

> > -----Original Message-----
> > From: Lever, Charles [mailto:Charles.Lever@netapp.com]
> > Sent: Wednesday, June 25, 2003 4:30 PM
> > To: Matthias Kittner
> > Cc: nfs@lists.sourceforge.net
> > Subject: RE: [NFS] Linux client network performance
> >=20
> >=20
> > hi matthias-
> >=20
> > it sounds like you've hit the IP fragmentation bug.
> > you should use NFS/TCP (the "tcp" mount option).
> >=20
> > probably it's your 2.4.19-based client that is
> > causing this problem.
> >=20
> > > -----Original Message-----
> > > From: Matthias Kittner [mailto:kittner@vrcom.de]
> > > Sent: Wednesday, June 25, 2003 4:57 AM
> > > To: nfs@lists.sourceforge.net
> > > Subject: [NFS] Linux client network performance
> > >=20
> > >=20
> > > [I am not a subscriber, please CC to my eMail!]
> > >=20
> > > Hello,
> > >=20
> > > we have the following problem:
> > >=20
> > > - 2 linux clients:
> > > 	2.4.19-16mdk
> > > 	2.4.20
> > > - Solaris NFS-Server (nfs.server 1.21)
> > > 	SunOS 5.7
> > >=20
> > > If we compile on one of the linux machines sometimes in=20
> > this compile=20
> > > process the whole network hangs resp. is so slow that one=20
> can wait=20
> > > between 10s or 2min to finish a "ls".
> > >=20
> > > "snoop" at the nfs-server machine show very/very much "UDP=20
> > > continuation"=20
> > > traffic between the linux client and the solaris server.=20
> > Killing the=20
> > > compile process stops this messages.
> > >=20
> > > Can anyone help us? Is this a configuration problem or a bug?
> > >=20
> > > Regards,
> > > Matthias
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: INetU
> > > Attention Web Developers & Consultants: Become An INetU=20
> > > Hosting Partner.
> > > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> > > Commission!
> > > INetU Dedicated Managed Hosting=20
> http://www.inetu.net/partner/index.php
> > _______________________________________________
> > NFS maillist  -  NFS@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU=20
> Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: Linux client network performance
@ 2003-06-25 14:58 Brasseur Valéry
  0 siblings, 0 replies; 8+ messages in thread
From: Brasseur Valéry @ 2003-06-25 14:58 UTC (permalink / raw)
  To: 'Lever, Charles'; +Cc: nfs

hi,

what's the "IP fragmentation bug" ?
what are the symptoms of this bug ?

thanks
valery
> -----Original Message-----
> From: Lever, Charles [mailto:Charles.Lever@netapp.com]
> Sent: Wednesday, June 25, 2003 4:30 PM
> To: Matthias Kittner
> Cc: nfs@lists.sourceforge.net
> Subject: RE: [NFS] Linux client network performance
> 
> 
> hi matthias-
> 
> it sounds like you've hit the IP fragmentation bug.
> you should use NFS/TCP (the "tcp" mount option).
> 
> probably it's your 2.4.19-based client that is
> causing this problem.
> 
> > -----Original Message-----
> > From: Matthias Kittner [mailto:kittner@vrcom.de]
> > Sent: Wednesday, June 25, 2003 4:57 AM
> > To: nfs@lists.sourceforge.net
> > Subject: [NFS] Linux client network performance
> > 
> > 
> > [I am not a subscriber, please CC to my eMail!]
> > 
> > Hello,
> > 
> > we have the following problem:
> > 
> > - 2 linux clients:
> > 	2.4.19-16mdk
> > 	2.4.20
> > - Solaris NFS-Server (nfs.server 1.21)
> > 	SunOS 5.7
> > 
> > If we compile on one of the linux machines sometimes in 
> this compile 
> > process the whole network hangs resp. is so slow that one can wait 
> > between 10s or 2min to finish a "ls".
> > 
> > "snoop" at the nfs-server machine show very/very much "UDP 
> > continuation" 
> > traffic between the linux client and the solaris server. 
> Killing the 
> > compile process stops this messages.
> > 
> > Can anyone help us? Is this a configuration problem or a bug?
> > 
> > Regards,
> > Matthias
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU 
> > Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly 
> > Commission!
> > INetU Dedicated Managed Hosting 
http://www.inetu.net/partner/index.php
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
> 


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: Linux client network performance
@ 2003-06-25 14:29 Lever, Charles
  0 siblings, 0 replies; 8+ messages in thread
From: Lever, Charles @ 2003-06-25 14:29 UTC (permalink / raw)
  To: Matthias Kittner; +Cc: nfs

hi matthias-

it sounds like you've hit the IP fragmentation bug.
you should use NFS/TCP (the "tcp" mount option).

probably it's your 2.4.19-based client that is
causing this problem.

> -----Original Message-----
> From: Matthias Kittner [mailto:kittner@vrcom.de]
> Sent: Wednesday, June 25, 2003 4:57 AM
> To: nfs@lists.sourceforge.net
> Subject: [NFS] Linux client network performance
>=20
>=20
> [I am not a subscriber, please CC to my eMail!]
>=20
> Hello,
>=20
> we have the following problem:
>=20
> - 2 linux clients:
> 	2.4.19-16mdk
> 	2.4.20
> - Solaris NFS-Server (nfs.server 1.21)
> 	SunOS 5.7
>=20
> If we compile on one of the linux machines sometimes in this compile=20
> process the whole network hangs resp. is so slow that one can wait=20
> between 10s or 2min to finish a "ls".
>=20
> "snoop" at the nfs-server machine show very/very much "UDP=20
> continuation"=20
> traffic between the linux client and the solaris server. Killing the=20
> compile process stops this messages.
>=20
> Can anyone help us? Is this a configuration problem or a bug?
>=20
> Regards,
> Matthias
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU=20
> Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly=20
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20


-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Linux client network performance
@ 2003-06-25  8:56 Matthias Kittner
  0 siblings, 0 replies; 8+ messages in thread
From: Matthias Kittner @ 2003-06-25  8:56 UTC (permalink / raw)
  To: nfs

[I am not a subscriber, please CC to my eMail!]

Hello,

we have the following problem:

- 2 linux clients:
	2.4.19-16mdk
	2.4.20
- Solaris NFS-Server (nfs.server 1.21)
	SunOS 5.7

If we compile on one of the linux machines sometimes in this compile 
process the whole network hangs resp. is so slow that one can wait 
between 10s or 2min to finish a "ls".

"snoop" at the nfs-server machine show very/very much "UDP continuation" 
traffic between the linux client and the solaris server. Killing the 
compile process stops this messages.

Can anyone help us? Is this a configuration problem or a bug?

Regards,
Matthias



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-06-26 16:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-25 19:40 Linux client network performance Lever, Charles
2003-06-26 16:50 ` s o f i a
2003-06-27  9:29 ` Matthias Kittner
  -- strict thread matches above, loose matches on Subject: below --
2003-06-25 18:09 s o f i a
2003-06-25 17:39 Lever, Charles
2003-06-25 14:58 Brasseur Valéry
2003-06-25 14:29 Lever, Charles
2003-06-25  8:56 Matthias Kittner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox