Subject: Re: AS 1200 + qlogic RAID
To: David Hopper <dhop@nwlink.com>
From: Greg Oster <oster@cs.usask.ca>
List: port-alpha
Date: 12/15/1999 14:04:47
David Hopper writes:
> Greg Oster wrote:
> > Is there an 'a' partition that automatically gets defined??!??!
> >
> > I'm curious to know that the (default) disklabels look like here...
> > (i.e. the output from 'disklabel sd1' and 'disklabel sd2')
>
> Well, if I had actually _read_ the disklabel to begin with, I would have seen
> :
>
> # /dev/rsd1c:
[snip]
> 3 partitions:
> # size offset fstype [fsize bsize cpg]
> c: 8380080 0 unused 0 0 # (Cyl. 0 - 3707)
> disklabel: boot block size 0
> disklabel: super block size 0
Ok, so it doesn't actually *have* a real label, just the faked-up one.
> I should add that this machine is coming from Digital UNIX 4.0E, and these
> disks
> were never touched AFAIK, unless by DEC UNIX's automatic install. Of course
> there
> is no /dev/sd1a _or_ /dev/sd2a: never was. That's just me, thinking that
> 'a'
> refers to the entire, unpartitioned disk, when every NetBSD doc under the sun
> says
> it's 'c'. (Okay, I'm done with the self-flagellation) That said, raidctl _s
> hould_
> have given the above error,
Did 'raidctl -C ...' give any sort of error?
(I realize the feedback from raidctl is (currently) rather weak... that
will hopefully change soon :) )
> but bear in mind that 'raidctl -C' means to force
> the
> RAID creation _regardless_ of the disklabels.
'raidctl -C' only forces creation regardless of *component labels*, not
disklabels. And 'raidctl -C' still requires there to be enough components
alive to actually start a RAID set. If the /dev/sd1a doesn't exist,
then when RAIDframe looks for that device, it shouldn't find it, and
would mark it as 'failed'. We're OK so far, since we can tollerate a
1-device failure in RAID 1. When /dev/sd2a fails in the same way, however,
sys/dev/raidframe/rf_disks.c:rf_ConfigureDisks()
should fail, and print a message like:
RAIDFRAME: Did not find any live disks in the array.
If it's not printing the above, then something weird must be happening
during the lookups on /dev/sd1a and /dev/sd2a (maybe it's not even getting
past the lookups??!. (but all of this should still have nothing to do with
bogus interrupts)
Later...
Greg Oster