I've just started experimenting with NFS over TCP and have a few
questions:
The Linux NFS-HOWTO states that:
> The disadvantage of using TCP is that it is not a stateless
> protocol like UDP. If your server crashes in the middle of a
> packet transmission, the client will hang and any shares will
> need to be unmounted and remounted.
I take this to mean that any client that is not actively accessing data
on the server at the time of a crash will be OK after the server
reboots?
As, I believe, some other OS's use NFS over TCP by default, how do they
get round this problem (or not)?
What is the 'best' way to get mount to try an TCP mount first - if that
fails, then try a UDP mount - I had a look at the mount source and
hacked in something to do this if the options -o tcp,udp are given - my
hack is very simple, if the TCP mount fails (for whatever reason), the
try a UDP mount - however, I don't know how 'safe' this is ...
Thanks
James Pearson
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == James Pearson <[email protected]> writes:
>> The disadvantage of using TCP is that it is not a stateless
>> protocol like UDP. If your server crashes in the middle of a
>> packet transmission, the client will hang and any shares will
>> need to be unmounted and remounted.
This is not really true. If the connection is broken, the client
should detect it, and automatically attempt to reconnect. It may be
that there are still bugs (I hope not) but the machinery is already
there.
> What is the 'best' way to get mount to try an TCP mount first -
> if that fails, then try a UDP mount - I had a look at the mount
> source and hacked in something to do this if the options -o
> tcp,udp are given - my hack is very simple, if the TCP mount
> fails (for whatever reason), the try a UDP mount - however, I
> don't know how 'safe' this is ...
It should be fairly safe: after all this is what most NFS clients do
anyway. I've had a patch available for quite some time on
http://www.fys.uio.no/~trondmy/src/util-linux-2.11n.dif.gz
that makes this easy. Just go to the function 'proto_probelist()' and
swap the order of UDP and TCP.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == James Pearson <[email protected]> writes:
> Thanks for the info - do you know what the 'best' combination
> of (2.4.X) kernel/patches gives the most stable NFS over TCP
> support?
As far as the client is concerned, 2.4.21-rc1 on its own should
suffice. I have no outstanding NFS over TCP patches beyond what I've
already fed to Linus and Marcelo.
Neil might have some further server side fixes though. I suggest that
you check his website.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hello!!
Actually I run NFS over TCP using RH 7.3 with a 2.4.20 recompiled kernel,
and all the clients run Mac OS X 10.2.5.
Besides some performance issues (10 MB/sec...ACK), rebooting the Linux box
doesn't lock up the Macs at all...
UNLESS, they try to access the NFS mount. But if files are open, and the
clients are working with them it's not a problem.
To me, it's better to shutdown all clients, then reboot the Linux box...
But my Linux server never crashes.
:)
So I can't tell you what to expect when that happens....
Dan Brunner
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 23, 2003 5:30 AM
Subject: [NFS] Questions about NFS over TCP
I've just started experimenting with NFS over TCP and have a few
questions:
The Linux NFS-HOWTO states that:
> The disadvantage of using TCP is that it is not a stateless
> protocol like UDP. If your server crashes in the middle of a
> packet transmission, the client will hang and any shares will
> need to be unmounted and remounted.
I take this to mean that any client that is not actively accessing data
on the server at the time of a crash will be OK after the server
reboots?
As, I believe, some other OS's use NFS over TCP by default, how do they
get round this problem (or not)?
What is the 'best' way to get mount to try an TCP mount first - if that
fails, then try a UDP mount - I had a look at the mount source and
hacked in something to do this if the options -o tcp,udp are given - my
hack is very simple, if the TCP mount fails (for whatever reason), the
try a UDP mount - however, I don't know how 'safe' this is ...
Thanks
James Pearson
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Work wrote:
> Hello!!
>
> Actually I run NFS over TCP using RH 7.3 with a 2.4.20 recompiled kernel,
> and all the clients run Mac OS X 10.2.5.
>
> Besides some performance issues (10 MB/sec...ACK), rebooting the Linux box
> doesn't lock up the Macs at all...
>
> UNLESS, they try to access the NFS mount. But if files are open, and the
> clients are working with them it's not a problem.
>
> To me, it's better to shutdown all clients, then reboot the Linux box...
That is unfortunate. It is possible to implement an NFS client such
that it will properly recovery from server failure and not interrupt
service to the application.
Spencer
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
>
> >>>>> " " == James Pearson <[email protected]> writes:
>
> >> The disadvantage of using TCP is that it is not a stateless
> >> protocol like UDP. If your server crashes in the middle of a
> >> packet transmission, the client will hang and any shares will
> >> need to be unmounted and remounted.
>
> This is not really true. If the connection is broken, the client
> should detect it, and automatically attempt to reconnect. It may be
> that there are still bugs (I hope not) but the machinery is already
> there.
Thanks for the info - do you know what the 'best' combination of (2.4.X)
kernel/patches gives the most stable NFS over TCP support?
>
> > What is the 'best' way to get mount to try an TCP mount first -
> > if that fails, then try a UDP mount - I had a look at the mount
> > source and hacked in something to do this if the options -o
> > tcp,udp are given - my hack is very simple, if the TCP mount
> > fails (for whatever reason), the try a UDP mount - however, I
> > don't know how 'safe' this is ...
>
> It should be fairly safe: after all this is what most NFS clients do
> anyway. I've had a patch available for quite some time on
>
> http://www.fys.uio.no/~trondmy/src/util-linux-2.11n.dif.gz
>
> that makes this easy. Just go to the function 'proto_probelist()' and
> swap the order of UDP and TCP.
That seems to work fine ...
Thanks
James Pearson
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
James Pearson wrote:
>I've just started experimenting with NFS over TCP and have a few
>
>
I too have started working with NFS over TCP and the only
problem I've seen so far is with flow control on the server
side...
Running the fstress benchmark locks ups NFSD tighter than
a drum in a matter of seconds... Now this probably has to
do with way that fstress sends its rpcs. Its seems to
"piggy-back" a bunch of messages in one TCP stream (meaning
ethereal show multiple rpcs in one tcp frame) which
is far from "normal" traffic. But it does hang the
which makes it very hard to get any of timings...
SteveD.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs