Questions about NFS over TCP
Subsystems (2)
I've just started experimenting with NFS over TCP and have a few questions:
The Linux NFS-HOWTO states that:
Quoted 4 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == 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
Quoted 8 lines · Trond Myklebust
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
" " == 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.
Quoted 4 lines
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?
Quoted 8 lines
> 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 ...
Quoted 7 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == 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:
Quoted 4 lines
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
Quoted 5 lines · Work
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.
Quoted 7 lines
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
Quoted 3 lines · James Pearson
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