According to the policy 'test it as much as possible and report the
bugs' let me add my 2 cents about NFS.
Beginning with approx. 2.0.23, I started noticing some unusual NFS
behavior:
We have a dedicated backup server machine. There are 13 machines
NFS-mounted to the servers (all are root-mounted). Each machine is
running Linux 2.0.27 - 2.0.30+pre2. Each machine's FS is about 1Gb in
size.
I noticed that:
a. The find command accross the whole NFS issued from the server used
to return 'I/O error' on a same file every time I ran it. Again the
very same file all the time. Needless to say, that the file was
perfectly readable and had no problems for 'local' finds.
b. The backup server machine (as well as the other ones) keep issuing
the messages of the following type from time to time:
/var/log/kernel: Jul 16 11:32:25 server kernel: NFS server bozo not responding, still trying.
/var/log/kernel: Jul 16 11:33:34 server kernel: NFS server bozo OK.
c. .. as well as:
/var/log/kernel: Jul 16 11:32:55 bar kernel: nfs_statfs: statfs error = 5
d. Worst of all, the backup script stopped working. It used to run the
find command thru the NFS to collect a list of files to back up, and
then run 'tar ... -T <list>' to do the actual backup. Now, tar just
terminates in the 1st quarter of the list! The exit code is 2. If I
remeber right, cpio doesn't have this problem. I understand that it is
definitely a tar problem, but it may be related to the NFS as well (if
say, tar puts more pressure on the NFS for I/O).
BTW, tar terminates all the time on the very same file (not the same
one as 'find' before)!!! And the file (surprize!) is perfectly
readable.
That's basically it. Now some more data. Clients mount each other with
the following options:
bozo:/ /nfs/bozo nfs posix,soft,rw,user,exec,suid,dev,noauto
As for the server, I tried to switch to hard mounts (it didn't help
though). Currently, server mounts everything with:
eatme:/ /nfs/eatme nfs hard,intr,posix,rw,user,exec,suid,dev,noauto
Best regards,