From owner-freebsd-scsi Thu Jul 2 14:52:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16327 for freebsd-scsi-outgoing; Thu, 2 Jul 1998 14:52:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16243 for ; Thu, 2 Jul 1998 14:52:29 -0700 (PDT) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by IAEhv.nl (8.8.7/8.8.7) with ESMTP id XAA28642; Thu, 2 Jul 1998 23:52:21 +0200 (CEST) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id XAA26473; Thu, 2 Jul 1998 23:52:20 +0200 (MET DST) From: Willem Jan Withagen Message-Id: <199807022152.XAA26473@surf.IAE.nl> Subject: Re: Using a DPT controller, pros and cons In-Reply-To: from Simon Shapiro at "Jul 2, 98 04:13:14 pm" To: shimon@simon-shapiro.org Date: Thu, 2 Jul 1998 23:52:20 +0200 (MET DST) Cc: wjw@IAEhv.nl, scsi@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You ( Simon Shapiro ) write: [ about DPT-raid's needing (M$)-DOS for configuration, and that it is relatively easy to disrupt a GOOD raid. ] => disks, bad canisters, bad enclosures, bad cables, bad power supplies, can => all cause disruption. => => It is also true that if the DPT ``looses'' a device on the bus, and the => device ``re-appears'' after a boot, the DPT still marks it red-flag. But => what is the alternative? To blindly take a device that previously FAILED => and make it good? Automatically? Nope, Your next point is more than true. Downtime is the most expensive problem you can have. It only problem is that it is hardly counted for in hard currency. Unless you go for a contract with penalty clause. => I agree that we could have the optimal utility ported, but frankly I was => convinced by my technical contacts at DPT that this is not a good idea. => If you had a failure, then you should explicitly override the failure tag. Well, als long as I decide that I've messed with my system, and I'm relatively shure that I never got to the writing stage of my OS. Then I see no problem. Remember that I once was saved by optimal.exe because I had a wire crossed and ended up with 2 clients for ID 6: tape and disk. Otherwise I would have lost the data that I wanted to backup in the first place. => BTW, I said it before, and I'll say it again; All my problems of this => nature have disappeared once I switched to DPT supplied disks, canisters, => enclosures and cables. I also, without fail, use ECC memory supplied by => DPT. Yes, it is expensive, but so is downntime. I know, but you have to realise that we have a different approach as to how we architecture our setup. EG. we have atleast 5 systems with modest storage requirements <20Gb. So that would require atleast US$25.000 for disks, controllers and cabinets. And those are the "cheap" home-brew cabinets. Note that most of the data is local to those systems, and we do not want to have 1 large NFS server with all the data. (Or we are seriously trying to avoid that) Just out of curiosity I would be interested in what a DPT set would cost: controller cabinet for 5 disks 4*4Gb disks in canister cables => There is a firmware bug/weakness regarding heavy => disk loads during a rebuild. I belive the proper people at DPT are aware => of it. I will post a new firmware when one is available. In the meantime, => use 7L0, NOT 7M0. If you insist on 7M0, have 7L0 available to re-load to => the controller. We've had this discussion when I was still running 7h0 => > BUT what I really missed are any applications to be able to figure out => > what the RAID is doing. ALL I see is that the controller and the drive => > LEDs are on. Other than that: nothing is known. Simon has promissed => > that ASAP he'll make some applications which will allow us to get more => > control over our RAID's => => 3.0-current has certain utilities. I will provide more once the migration => to CAM and the initial release of the 5th generation controllers is out. Is it possible to back-port these to 2.2-STABLE? Or does it require too much changes to the way you interface with the card? => > The other issue: => > I've done 3 'dd if=/dev/zero of=/mnt?/bar' in parallel on the => > system. => > 2 go to the DPT RAID-1 and RAID-5 => > 1 goes to a seperate MICROPOLIS on the onboard ahc0 contoller. => > => > Now the MICROPOLIS get a sustained write stream of something like 2.7 => > Mb/sec. The two RAID's do not stream the data at all. There's seconds of => > time where either of the disks doesn't take any data. Then one disk has, => > like 5Mb/sec, and the other 0-4 blocks/sec. => > (And this get worse if rebuild are on the way) => => Forward this to DPT. The FreeBSD code has nothing to do with such things => :-( You can try and run dptcntl to see the data and transaction rates, the => longest delay and a host of other metrics. I have some stuff in a DPT/tools directory, but they do not seem to work. First I had to change from major devno 130 to devno 88, but still no go. I'm starting to wonder if my mirror of your DPT directory is still operational? Where do you currently keep your FreeBSD work? The performance issue, I'll get to in another thread. thanx, --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message