Mogens V. wrote:
No log entries on the server, you mean?
That's possibly fairly easy to diagnose (which isn't the same thing
as fixing). Run tcpdump on the client and server, filter to see
only NFS-related stuff between those two hosts, and see what who is
not responding to whom. On very common cause of NFS timeouts used
to be a lack of threads on the NFS server: each thread answers a
request (basically a packet in the old days of UDP-based NFS), and
there is a fixed number of threads, so if they are all busy, the
packet is simply dropped, and the client is expected to retransmit
it. The client can't tell the difference between this and a
crashed/missing/unreachable NFS server, so you see timeouts.
As I recall, there are two solutions to this: the first is to
increase the number of threads. This ensures that there will
always be one available when a request comes in. However, it's
not a perfect solution, because for a client to believe the NFS
server is OK, the server has to not only assign the request to
a thread but also do the physical I/O (read or write from disk)
and return a packet. That means that the more I/O load you have
on your server, the longer clients are going to have to wait, and
the more danger of timeouts. As far as I know, the only solution
to this (other than increasing disk I/O capacity of the server)
is to increase the timeouts on the clients and increase the time
before they retransmit requests (which further bog down the
Anyway, the point is that timeouts aren't necessarily an indication
of a bug or anything like that. Sometimes they can just be an
indicator that performance tuning is needed.
I suspect that as far as choosing Linux, FreeBSD, or Sun goes, you
are going to have advantages and disadvantages with any of those
in the area of stability and performance, because NFS compatibility
between client and server just varies with the different combinations.
As far as I know, Coda isn't really ready for prime time, so I would
personally avoid that. AFS isn't a bad option, but I'm not really
sure if it offers any huge advantages in your situation (which,
as far as you've described, is entirely confined to a small LAN).
On the other hand, if the NFS interoperability problems turn out to
be unsolvable, then any other filesystem might be a better choice. :-)
AFS probably has an advantage here since as far as I know there aren't
multiple independent implementations of AFS, and interoperability is
usually better between ports of the same implementation of something
than it is between independent implementations.
I don't think ZFS is ready for prime time either, yet, although it
promises to be ready pretty soon (maybe 6 months). Because it uses
copy on write for all writes, thus turning essentially all writes
into sequential I/O, it should be a pretty good combination with NFS,
since NFS really benefits from a filesystem that can complete write
Personally, I wouldn't go with Veritas, because I just don't see the
benefit over plain UFS, now that UFS has support for large filesystems,
journaling, etc. Especially since UFS is built in, which means
administration is simpler.