6.0 on Dell 1850 with PERC4e/DC RAID?

Doug Ambrisko ambrisko at ambrisko.com
Sat Jan 14 11:10:54 PST 2006


Scott Mitchell writes:
| On Thu, Jan 12, 2006 at 04:41:17PM -0800, Doug Ambrisko wrote:
| > Scott Mitchell writes:
| > | 
| > | That's a pity.  Maybe Doug was thinking of one of the aac(4) based PERC
| > | cards?  Still, something I can run out of cron to check the array status
| > | should be fine.
| > 
| > Are you refering to this Doug.  The Linux ioctl shim requires one file
| > that hasn't been committed yet.  Scott L. & ps have it.  I may commit
| > it now that I'm back.  This lets all of the Dell/LSI Linux tools 
| > run on FreeBSD including the firmware update tool.  The caveat is
| > that with the driver re-do it seems the certain things in the ioctl
| > path causes the firmware to lock-up.  I haven't been around enough
| > to help with that problem.  I have a binary that locks it up pretty
| > quick.
| 
| Hi Doug,
| 
| I was actually referring to Doug White, who said:
| 
| >From what I remember, you will receive status-change kernel messages when
| >disks disappear, rebuilds start, and so forth. So for most day-to-day
| >manipulation you should be fine.
| 
| It wasn't clear if this applied to the amr(4)-based PERC cards or just the
| aac(4) ones.

Yes that only applies to the aac based machines and not amr based machines
(ie. Adaptec versus LSI).  With LSI you have to poll the controller
for RAID events and that is not public.
 
| Sounds like the re-worked amr driver will be very much better, at least
| once a few more bugs have been ironed out of it.

Yes.
 
| > Most of the existing monitoring tools have bugs.  The Linux tools
| > tend to be better but the last copy of MegaMon leaked shared memory
| > then quit.  We have a tool at work but it is encumbered so we can't
| > give it out.
| >  
| > | > I did find a program   
| > | > posted to one of the freebsd lists called 'amrstat' that I run  
| > | > nightly.  It produces this kind of output:
| > | > 
| > | > Drive 0:    68.24 GB, RAID1 <writeback,no-read-ahead,no-adaptative- 
| > | > io> optimal
| > | > 
| > | > If it says "degraded" it is time to fix a drive.   You just fire up  
| > | > the lsi megaraid tools and find out which drive it is.
| > 
| > This is probably a faily good scheme.  Caveat is that you can have
| > a "optimal" RAID that is broken :-(
| 
| That's pretty sucky, but presumably not a FreeBSD-specific problem?
| Despite that, I'm reasonably hopeful that a scheme like this along with
| good backups (which we have) will be enough to avoid any major disasters.

It's not a FreeBSD specific problem.
 
| Is Dell's support any better if you tell them you're running RedHat?

We can sort-of run RedHat.  That is, we ran the Linux RAID binaries 
from LSI & Dell with the Linux ioctl emulation layer I did on FreeBSD.
I netboot Linux sometimes to verify some things.

Doug A.


More information about the freebsd-stable mailing list