From owner-aic7xxx Thu Feb 25 12:19:28 1999 Delivered-To: aic7xxx@freebsd.org Received: from lacrosse.redhat.com (lacrosse.redhat.com [207.175.42.154]) by hub.freebsd.org (Postfix) with ESMTP id 16FD315049 for ; Thu, 25 Feb 1999 12:19:09 -0800 (PST) (envelope-from dledford@redhat.com) Received: from kabal.redhat.com (root@kabal.redhat.com [207.175.42.20]) by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id PAA10398; Thu, 25 Feb 1999 15:18:53 -0500 Received: from redhat.com (dledford@kabal.redhat.com [207.175.42.20]) by kabal.redhat.com (8.8.7/8.8.7) with ESMTP id PAA15821; Thu, 25 Feb 1999 15:18:55 -0500 Message-ID: <36D5B02F.B9E0605C@redhat.com> Date: Thu, 25 Feb 1999 15:18:55 -0500 From: Doug Ledford Organization: RedHat Softwarem, Inc. X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Robert G. Brown" Cc: Maxwell Spangler , AIC7xxx@freebsd.org Subject: Re: Adaptec 7890 and RAID portIII RAID controller Linux Support References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "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 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