Date: Thu, 2 Jul 1998 23:52:20 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAE.nl> To: shimon@simon-shapiro.org Cc: wjw@IAEhv.nl, scsi@FreeBSD.ORG Subject: Re: Using a DPT controller, pros and cons Message-ID: <199807022152.XAA26473@surf.IAE.nl> In-Reply-To: <XFMail.980702161314.shimon@simon-shapiro.org> from Simon Shapiro at "Jul 2, 98 04:13:14 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807022152.XAA26473>