Hi,
I have finally installed my server, and I'm encountering NFS problems:
The system installed is RH 6.0.
A local directory on the Linux server is exported to a Solaris 2.5.1 client.
both the Linux directory and the Solaris directory over which it is mounted
has a 1777 permission (same as /tmp).
The /etc/exports file is:
/tmp-raid *(rw)
The directory is mounted on the solaris client using:
mount -o vers=2 linux:/tmp-raid /tmplinux1
The mount seems to work fine, and functions as a remote temporary directory.
user can "cd" to the directory, create files, remove them, etc.
the problems begin when a user (non-root) cd's to the directory and typed
'pwd'. This triggers the following message on the Linux console:
svc: unknow program 100227 (me 100003).
and an error is printed on the solaris client.
once this happenes, the user can no longer remove files while he is in the
directory. i.e. :
% cd /
% rm /tmplinux1/x
will work, while:
% cd /tmplinux1
% rm x
will fail! Also, pwd no longer works (prints an error message).
I have tried the following:
kernel-2.2.5-15 (stock RH 6.0)
kernel-2.2.5-22 (RH 6.0 updates)
kernel-2.2.9
kernel-2.2.10
knfsd-1.2.2 (stock RH 6.0)
unfsd-2.2beta43
All these either didn't work at all, or worked the same way as I noted above
(stock RH 6.0 components).
I have also tried Ariel's suggestion of adding the '-n' flag, both to knfsd
and to nfsd-2.2beta43, but both versions do not recognize the '-n' flag!
Anyone has an idea?
I'm even considering downgrading to RH 5.2, assuming it's NFS is more stable,
even if performance is worse.
thanks,
Udi
n.b. If you are interested about my RAID experiments, please read below:
-----------------------------------------------------------------------
My system 3 IBM disks, 22GB ATA 7200RPM, adn an intel server motherboard
(T440BX).
Installed stock RH 6.0. 3 disks installed as /dev/hda, /dev/hdb, /dev/hdc,
with ATAPI CDROM as /dev/hdd.
(1) The kernel reports that the BIOS says that /dev/hda is PIO, while /dev/hdb
and d/ev/hdc use DMA. weired.
(2) The kernel reports that /dev/hda and /dev/hdb use 2748/255/63 geometry,
while /dev/hdc is 43800/16/63. Even more weired.
Since I wanted all 3 disks to look exactly the same, I solved (2) by adding
hdc=2748,255,63 to the kernel parameters in the /etc/lilo.conf file.
Finished installing with All 3 disk share exactly the same partition table: a
1GB partition on each disk for root, /usr and /data, plus 100MB swap on each
partition, plus 20GB on each for RAID.
measured performance with hdparm -t /dev/hd[abc] and got a disappointing
2.3MB/s. Solved with hdparm -d 1 /dev/hd[abc]. speed now goes to 16MB/s.
somehow this works even for large blocks. The command:
time dd if=/dev/hda of=/dev/null count=1024 bs=131072
takes 7-8 seconds, yielding 16MB/s actual disk throughput !! never expected
this!
The DMA setting above is kept somwehere on a file, as it retains the value
even after reboot.
Now comes the RAID part. I made a linear raid, by creating a description in
/etc/raidconf (or whatever the control file is called). initialized it by
raidstart /dev/md0, and then mke2fs /dev/md0, then mount /dev/md0. works fine.
reboot system. no good. it seems the init scripts try to recognize the RAID
array (using something called persistent-superblock in /etc/raidconf) but
fails. As a result fsck tried to check /dev/md0 but fails. I have to remove
/deev/md0 from /etc/fstab so that the boot can finish.
checking kernels 2.2.5 through 2.2.10 I find that RedHat have applied the
"alpha" RAID patch to their kernel containing this more advanced RAID driver.
The stock 2.2.x kernel doesn't even have this option. I end up finding the
patch for 2.2.6, applying it to 2.2.10, fixing the single patch fail, and
rebuilding 2.2.10 with the patch. works like a charm. The disk is now
recognized automatically as part of the boot sequence.
WARNING: the raidtools RPM ships with RH 6.0 requires this patch! i.e. it will
not work with a stock 2.2.x kernel!!
