RE: NOAAPort data server x86 configuration (fwd)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Fri, 13 Oct 2000 23:44:22 -0400
From: Dan Vietor <address@hidden>
To: 'Jim Koermer' <address@hidden>, address@hidden
Subject: RE: NOAAPort data server x86 configuration

I'll chime in with a few comments.  These are from direct experience
between Solaris and Linux.

1) Linux NFS product is not as good as Solaris's.  I've run into several
problems, some well documented, with Linux's nfsd.

We run Lantastic TCP/IP software here and it has a nasty habit of
leaving NFS file handles open.  If you remove these files prior to
closing the handle, it leaves the inodes in a lost state.  These files
are neither deleted or available.  The inodes will continue to collect
until the disk fills up.  I've seen this with AIX and Solaris and these
nfsd/disk implementations recover safely without a problem.  The only
way to solve the problem on Linux is to reboot and do a forced fsck to
remove "deleted inodes with 0 dtime".  I'm hoping moving to RedHat 7
will solve this problem but I'm not holding my hopes up.

There is a known problem with nfsd that after long periods of time,
cause nfsd to lock up.  I've seen reports on this on the RH Knowledge
Database.  Basically, internal buffers or something eventually hangs and
you cannot kill the nfsd with even a kill -9.  If you let this go, the
system will eventually hang completely.  This requires a reboot to solve
the problem.  This forces me to reboot my web server about once a month.
We ran the web server on Intel Solaris with similar hardware for over a
year without a single reboot.  Linux isn't as reliable.

2) Linux disk contention is a major problem.  I've noticed on systems
where the disk is being constantly used that disk access can almost
grind to a halt at times.  This is on IDE drive systems and I'm not sure
if this applies to SCSI drives.  If you put a constant load on a hard
drive where the disk light is on about 80% of the time, eventually, disk
contention will get to a point where the whole system slows to a crawl.
Removing even small files can take up to 5-10 seconds to accomplish.
This is currently jeopardizing one of our projects to the point where
I'm contemplating moving to another operating system.


From my experience, I just don't believe the Linux kernel, which is the
youngster on the block compared to Solaris and BSD, is even close to the
level that Solaris and BSD are.  The more I use Linux in operational
settings, the more gotchas I run into.  It still has some catching up to
do!

Don't get me wrong... I like Linux in terms of its look and feel, sys
admin, availability of precompiled tools and software availability.  I
still prefer Linux over Solaris for a development environment.  I guess
I could equip Solaris with all the GNU stuff eventually but right now,
Solaris's base tool set is no different today than it was when Solaris
first came out 10 years ago and this limits my ability to use the
system.

Also, we're sort of stuck between trying to keep costs down, thus
avoiding Sparc Solaris and other Unix workstations, and corporate
approved setups which keeps us from going to setups like FreeBSD.  Intel
Solaris would be a great compromise but our problems with
incompatibilities involving newer PC hardware platforms make Intel
Solaris almost impossible to use.  So Linux looks like the lesser of all
evils right now but its not perfect.

________________________________________________________
Daniel Vietor               Mail: address@hidden
Unisys Corp                 Title: Engineer/Meteorologist
221 Gale Lane               Phone: 610-925-5206
Kennett Square PA 19348     Fax: 610-925-5215