On Wed, 16 Dec 1998, Robert M. Hyatt wrote:
> But linux can work perfectly with suns...
Hmmm, linux can work with suns, but I would take issue with the term
"perfectly". There are a number of rough edges to be overcome,
especially with linux servers and sun clients. sun servers and linux
clients are a safer bet, but need tuning. linux servers and linux
clients seem to be fine, and of course sun to sun is also fine.
Two difficulties that we have encountered are:
First, that the wsize/rsize need to be set on a linux client to get
decent performance reading/writing to sun servers. We use
wsize=8192,rsize=8192.
Second, one needs turning off caching on sun mounts of linux exports.
We discovered that this was necessary when trying to make a really large
package (perl) on a Sun from sources exported from a linux box.
Curiously, the make would get 70% of the way through and then bomb, and
it would bomb at different points (reading different files) on each try.
What was happening was that the cache image of the files had a certain
(low) probability of being corrupted -- the direct symptom was that a
stat of the files showed them to be "empty" (they weren't, of course) --
sometimes. Then a few minutes later, they'd stat correctly and maybe a
different one would be "empty" and have the wrong timestamp on the next
make attempt. We'd lived with this problem for years without realizing
it because the probability was rather low (and probably depended on the
volume of NFS traffic) and because we were exporting userspace from Sun
to linux and not the other way around, which normally kept the
linux->sun NFS traffic low.
It may be that caching is fixed by now in the linux nfsd/mountd combo --
I haven't messed with this recently -- but it is an area of concern that
one should be aware of when thinking about engineering a network. At
the very least, one should look into the more recent versions of nfs
(especially the kernel nfs) to see if they have addressed/repaired the
caching problem. The turn-off-caching solution seems to work well
enough as well, but probably costs a bit in performance if that is very
important to you.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
