Hi,
Original Question
-----------------
We are currently evaluating an SGI octane for use with a seismic processing
system (ProMAX).
Our file servers are Solaris 2.5(.1). The SGI runs IRIX 6.5.
I have some trouble with the SGI:
1. It has problems accessing the file servers:
Nov 4 18:07:07 6A:IRIS unix: NFS server eirene not responding still
trying
Nov 4 18:07:07 6A:IRIS unix: NFS server eirene ok
This happens very often with different file servers, no other machine
in the network has similar problems.
2. netstat -i shows collisions:
# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs
Coll
ef0 1500 193.97.206.160 IRIS 8754361 0 8969852 2685
3768
lo0 32992 loopback loghost 16643 0 16643 0
0
We use 100 MBit ethernet (switched) in full duplex mode on all machines,
so we should get no collisions at all.
3. The SGI exports it's ProMAX installation via NFS. On the clients, it is
automounted on /sgi. When i cd to /sgi/sys, then do an "ls", i get the
directory listing as expected. When i then cd down to the subdirectory
named exe, and do an "ls", i get this:
NFS readdir+ failed for server IRIS: error 2 (RPC: Can't decode result)
NFS readdir failed for server IRIS: error 2 (RPC: Can't decode result)
This happens ONLY with /sgy/sys/exe, not with other directories on the
same level as exe...
This happens on all SUN clients, not on the SGI.
Meanwhile i have disabled the automounter on the SGI and mount everything
via the fstab, using NFS version 2 (but this doesn't seem to help). We never
had such problems with any SUN.
Are there any known problems integrating a SGI into a SUN environment ?
Something, that i can tune somewhere ?
Solution(s)
-----------
ad 1: I stopped using the automounter on the SGI, and changed back to
/etc/fstab instead. There, i used the following settings:
rsize=8192,wsize=8192,timeo=50,retrans=12
This cured the nfs problems on the SGI (NFS client)
ad 2: not solved yet. Still waiting for input from SGI support.
ad 3: I needed to add the "-32bitclients" option to /etc/exports on the
SGI, so that SUN clients are happy now.
BTW: due to the software being tested, we needed to go back to IRIX 6.4.
Furthermore, i was pointed to the following newsgroups: comp.unix.solaris
andcomp.sys.sgi.*
Note on SGI free disk space calcultation
----------------------------------------
The SGI shows an interesting beaviour:
This is from the NFS server (a SUN):
SUN# df -k /terra1002/advance/data/
Filesystem kbytes used avail capacity Mounted on
brigit:/TERRA1002 3991640 3592488 0 100% /terra1002
...and this from the SGI (NFS client):
SGI# df -k /terra1002/advance/data/
Filesystem Type kbytes use avail %use Mounted on
brigit:/TERRA1002 nfs 3991643 3592487 399156 91 /terra1002
The SGI calculates : avail = kbyes - used,
and not: avail = 0.9 * kbytes - used (if minfree == 10 %)
The result is, that the SGI believes, that the remote disk still has 400 MB
free and tries to write to it, meanwhile I get lots of "filesystem full"
messages on the NFS server ! This is more or less lethal for our software (or
better: our data), which tries to fill up a disk and then skips to the next
free disk (taken from the software's config file). On SUN, this works almost
perfect.
Has anyone seen this before ? Is there a workaround ? I heard, that i could
tune all my NFS servers with tunefs, but i don't want to change here
everything just for a 3 week evaluation...
Thanks to
---------
Olivier.GIRAUD@cedelgroup.com
anders@hmi.de (Thomas Anders)
Steven Dodd < S.Dodd@leeds.ac.uk>
Anthony Worrall <Anthony.Worrall@reading.ac.uk>
bbyoung@amoco.com (Brad Young )
"John P. Dodge" <john.p.dodge@boeing.com>
John Stoffel <john.stoffel@ascend.com>
"Brion Leary" <brion@dia.state.ma.us>
"Franczyk, Gary" <gfranczyk@carbomedics.com>
Carlo Tosti <carlot@interlog.com>
Stefan
,,,
(o o)
--------------------------------o0Oo-(_)-oO0o---------------------------------
Stefan Voß Phone: # 49 (0) 5139-9908-51
System and Network Administration Fax: # 49 (0) 5139-9908-10
TerraData Geophysical Services GmbH e-mail: s.voss@terradata.de
Ehlbeck 15 a
D - 30938 Burgwedel, Germany
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:52 CDT