OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: SCSI, U2W in particular?, and poor performance...
From: Brad Knowles (blkskynet.be)
Date: Sun Mar 05 2000 - 06:59:56 CST

At 11:45 PM -0800 2000/3/4, Justin Robertson wrote:

> The entire point I'm trying to make here is that faster hardware is
> running slower, and I'd like to find out why.

        You have been told why, you just haven't been paying attention.

        You're almost certainly using Linux with default asynchronous
writes on the low-end box, while the administrator of the high-end
box may have been smart and disabled this "feature" of Linux.

        While asynchronous writes do make the box a lot faster on disk
operations, they're also a lot more dangerous, and you'd almost
certainly lose files (if not the entire filesystem, or the entire
machine) if you pulled the plug (as Wietse suggested).

        According to RFC 1123, the Internet Host Requirements document,
you *MUST* *NOT* lose e-mail, just because of something stupid like a
power failure, so you cannot use Linux with asynchronous writes on a
sendmail mqueue or a postfix mail queue.

        You either have to change the mount point options for that
filesystem to include "sync" ("async" is the default, and does not
need to be specified), you you must use the "chattr" command (as
suggested by Rafi) to disable asynchronouse writes on that directory.
In fact, you need to use it recursively on your entire
/var/spool/postfix directory tree (or whatever directory tree you
specified that postfix should use for its mail queue).

        In addition, proper Internet e-mail administration requires that
you syslog at least enough information about incoming and outgoing
mail that you can always determine what happened to a particular
e-mail message, and when (you should keep these logs around for at
least a few days, and the longer the better).

        If you syslog as much information as you should, and you change
your Linux installation to use slower but safer synchronous writes
(as opposed to faster but more dangerous asynchronous writes), you
will probably find that the larger machine is considerably faster
than the smaller one.

        Note that if you were using FreeBSD (or other members of the *BSD
family), you could safely enable "softupdates" on the postfix mail
queue filesystem, and you would get all the speed of asynchronous
writes (or more), without the dangers.

        Once you get enough sysadmin experience under your belt, you will
come to realize that IDE may be fine for desktop workstations, but
that it does not fare well in most server applications. It doesn't
handle multi-tasking operations as well as SCSI, is not as
expandable, and is not as robust.

        In addition, it is not as fast as SCSI can be, since vendors
always come out with their fastest high-end drives on SCSI first, and
if they ever bring those features and speed down to IDE, it is much,
much later (sometimes years later).

        Finally, did you conduct your low-end tests on the machine itself
(i.e., on the loopback network), while the high-end tests were
conducted across the network? If so, that could have a major effect,
as the network might be congested, the high-end server might be
heavily loaded, etc....

        Basically, you didn't give us enough details about your testing
environment, and what guesses we can make about it indicate that you
didn't properly prepare either system. 

-- 
  These are my opinions and should not be taken as official Skynet policy
=========================================================================
Brad Knowles, <blkskynet.be>       Sys. Arch., Mail/News/FTP/Proxy Admin

Note: No Microsoft programs were used in the creation or distribution of
this message. If you are using a Microsoft program to view this message,
be forewarned that I am not responsible for any harm you may encounter as
a result.

See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for
details.