We are currently using NFS over TCP for news purposes. Is that a bad thing?
Not necessarly. Do you have a reason for needed tcp such as your are doing long haul networking?
However there are a lot of things that can go wrong with tcp that can't with udp (there are lots of very broken tcp implementations in this world: not ours of course:-) I would sugest disabling tcp and see what happens. If things stay the same or get better just leave it that way. If not you had tcp turned on for a reason.
We currently run with NFS v2/UDP on our NetApp. The change from v3 to v2 resulted in a noticeable decrease in expiry time for us.
The disadvantage of NFS v2 is that you won't be able to get number of inodes (files) via NFS. I like the suggestion from Guy Harris to deal with this: Use two mount points for the NetApp file system - one NFSv2 for the main News spool, and one NFSv3 to be able to check inodes, selected by suitable mount options on client.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
+--- In our lifetime, sthaug@nethelp.no wrote: | | We currently run with NFS v2/UDP on our NetApp. The change from v3 to v2 | resulted in a noticeable decrease in expiry time for us. | | The disadvantage of NFS v2 is that you won't be able to get number of | inodes (files) via NFS. I like the suggestion from Guy Harris to deal with | this: Use two mount points for the NetApp file system - one NFSv2 for the | main News spool, and one NFSv3 to be able to check inodes, selected by | suitable mount options on client.
When running v3, the main drawback (in news service) was the READDIR+ vs READDIR performance. When you hit a group like misc.jobs.offered and have a 3 week expire time, that client will sit there for a while waiting for the op to complete. We stuck with v2 and udp over a backend network.
I never did try the suggestion from Guy. I would imagine it works as advertised.
Alexei
-
alexei＠deepthroat.cimedia.com -
sthaug＠nethelp.no