Date: Thu, 25 Feb 1999 15:18:55 -0500 From: Doug Ledford <dledford@redhat.com> To: "Robert G. Brown" <rgb@phy.duke.edu> Cc: Maxwell Spangler <maxwell@clark.net>, AIC7xxx@freebsd.org Subject: Re: Adaptec 7890 and RAID portIII RAID controller Linux Support Message-ID: <36D5B02F.B9E0605C@redhat.com> References: <Pine.LNX.3.96.990225124113.3721A-100000@ganesh.phy.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"Robert G. Brown" wrote:
>
> Masterful work, Doug! Not since I read Sun's NFS Configuration and
> Capacity Planning white paper six or seven years ago have seen such a
> cogent discussion of server disk configuration (RAID or not, really).
Thanks :)
> One question:
>
> On Thu, 25 Feb 1999, Doug Ledford wrote:
>
> (....deleted...)
> > 3. Before you start to create your RAID arrays, make sure that the /boot
> > directory is either on a non-raid / partition, or on it's own partition. LILO
>
> Would a reasonable solution be to use a single IDE disk as a boot/swap
> disk and reserve the SCSI channel(s) for striping or RAID as you
> describe? I've experience a little bit of weirdness running IDE and
> SCSI in the same system, but it might have been hardware mediated
> weirdness.
That's possible, but what I've found to be a good method is to do something
like this:
/dev/sda1: 200MB
/dev/sda2: Rest of disk
Then I copy that exact same paritioning to all the rest of the disks. When I
actually lay it out, /dev/sda1 becomes the self sustaining /boot partition and
/dev/sdb1, /dev/sdc1, /dev/sdd1, etc all become identical swap partitions that
are all set up with exactly the same priority level in the fstab. This way,
all the swap partitions end up being their own psuedo raid stripe, but they
bypass the VFS code and go directly into the block driver. They are also
fairly small partitions by total drive standards and are located in the front
of the disk close to the RAID partitions so that you avoid the long seek
problem I mentioned when you split a disk into several larger chunks. That's
about as close as you can get to the absolute maximum performance of the array
while not using a dedicated SCSI disk or IDE disk. It also drastically
increases swap performance.
There is a second reason for this as well. I've identified at least one area
of problems in the mid-level SCSI code, and that involves locking between two
totally different scsi low level drivers (in this case, BusLogic and
aic7xxx). I have a system were I can reliably produce lockups and other
errors by mixing the two brands of controllers and drivers, but where either
one by themselves works fine with the same setup. Aka, 2 aic7xxx cards to
handle the two busses works fine, 2 buslogics cards to handle the two busses
works fine, 1 buslogic and 1 aic7xxx based cards spells problems. This
happens to be very high on my list of things to fix. Unfortunately, I'm
afraid the answer may be that it will show up in 2.3 with other mid level
modifications. However, since I can cite at least one system that acts this
way reliably, I'm recommending people try and be homogeneous in the SCSI/IDE
configuration on a single linux system for the time being. Note, very few
people have even considered that this might be a problem, so that gives some
sort of indication about how many people have mixed scsi systems. I also
suspect that some scsi drivers, like the aha152x driver, that are polling
based driver and essentially force serialization of the complete SCSI
subsystem by the fact that the driver locks the CPU down and spins for a long
time instead of queueing things up and doing everything simply on completion
interrupts also plays a part in this. I suspect that those drivers can
peacefully co-exist with the likes of the aic7xxx driver. It's only the
mixing of two SMP optimized, parallel operating drivers that causes problems.
When I actually get this pinned down, then I'll comment further.
--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36D5B02F.B9E0605C>