I've gone and read all the NFS posts, but nothing quite seems to touch the issue I'm having when trying to copy the contents of a SCO-shared NFS dir from a RHEL ES5 client. The SCO boxes run SCO OpenServer 5.0.5, 5.0.6 and 5.0.7.

The share/mount is (now) extremely simple (names changed to protect the innocent):

SCO (192.168.1.1) --
/etc/exports: /dir/subdir -root=192.168.1.2,ro

RHEL (192.168.1.2) --
/etc/fstab: 192.168.1.1:/dir/subdir /mnt/shared_dir nfs ro 0 0

The share mounts fine, dir listings work fine, but copying the contents from the SCO box to the RHEL box is so slow that even tiny 100Kb files can take as much as 15 minutes (!?!?!?!) to transfer.

The RHEL ES5 box complains with these messages:

Sep 21 15:16:08 RHEL kernel: nfs: server SCO not responding, still trying
Sep 21 15:16:08 RHEL kernel: nfs: server SCO not responding, still trying
Sep 21 15:16:08 RHEL kernel: nfs: server SCO OK
Sep 21 15:16:08 RHEL kernel: nfs: server SCO OK

The file copy (cp -arv /mnt/shared_dir/* .) will ocassionally surge for maybe ten or so miniscule files, and then hang again on a file a bit over 100Kb. I've tried specifying the read and write block sizes, but that had no effect.

I have followed some troubleshooting steps I found with respect to SCO NFS, such as stopping and starting th biod processes during the file copy, but this did not appear to have any effect on the issue.

I have reproduced this scenario on different machines, on different networks, and I am confident it is not due to network congestion, hardware or network drivers.

What complicates this for me is that when I mount the very same SCO NFS share on an old Red Hat 8.0 box, copying the SCO NFS shared files screams by with lightning speed (Ok, everything's relative--but it's acceptably fast).

I have shared a sizeable dir on the Red Hat 8.0 box and mounted that on the RHEL ES5 box. The dir copy is just as fast as should be expected.

So, I believe I should be able to assume that I have my NFS configurations correct because they work in the scenarios that don't put together SCO and RHEL ES5.

I have even gone and tested the RHEL ES5 box with both iptables and selinux disabled, and this doesn't help the problem with getting the files off SCO (and, believe me, we want to get the files off the SCO boxes).

I have tried mounting the NFS share with a variety of explicit options, a small sampling of which are:

192.168.1.1:/dir/subdir /mnt/shared_dir nfs sync,auto,ro,intr,hard 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs sync,auto,ro,intr,soft 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs sync,auto,ro,intr,nfsvers=2 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs ro,nfsvers=2 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs ro,hard 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs ro,intr,hard 0 0
192.168.1.1:/dir/subdir /mnt/shared_dir nfs sync,auto,ro,intr,nfsvers=1 0 0

When I explicitly specify NFS version 1, the RHEL box complains with:
"NFS version 1 is not supported." SCO NFS doesn't support version 4 (at least not the version we have).

I have also tried mounting the SCO share on a Fedora 6 box, but this likely didn't work for the same reason the RHEL ES5 box didn't, whatever that reason might be.

There are no errors logged on the SCO box in /var/adm/messages or /var/adm/syslog. The SCO box appears to act as though it believes everything is peachy.

All the proper services (nfs, lockd, portmap, etc.) are running on both SCO and RHEL ES5. I can get NFS to work just "swell" between a variety of other combinations of boxes, it's just the RHEL ES5 to SCO combo that is driving me insane.

Does anyone have any clues/suggestions as to what path to follow to track down the problem? I have a support ticket in with Red Hat, but they are not being terribly responsive.

Thanks!

Well, Red Hat support finally got back to me.

Apparently, for those who may be interested, someone at Red Hat has decided to default the NFS protocol to TCP on RHEL ES5.

The RHEL ES5 installed man page, however, says this about the issue:

udp Mount the NFS filesystem using the UDP protocol.
This is the default.

Since I actually do read man pages, I figured setting the protocol to the *default* would be a silly waste of time--I mean, why bother, right? I did try setting it to TCP, and that bombed in same fashion as all the rest of my attempts

Well... so much for reading man pages.