Brian Buhrow writes:
> 	I just want to clarify, since I think you  may have missed my
> question, even though you inadvertently answered it.
> 
> On Aug 13,  6:28pm, Greg Oster wrote:
> } Subject: Re: RAIDFrame and NetBSD/sparc booting issues
> } > Thiss would imply that disklabel -r sd0 or wd0
> } > should read the label out of this protected region, assuming the raid
> } > partition includes the entire disk.  Is this right?
> } 
> } No.  If the disklabel usually lives at block 0 for the arch, then the
> } disklabel for raid0 will be found at block 0 of the data area of the RAID 
> } set.  (i.e. typically at block RF_PROTECTEDSECTORS of the first component 
> } of any RAID set).  Doing a 'disklabel sd0' or 'disklabel wd0' will 
> } get the label from the underlying drive, but that will never contain 
> } the disklabel for raid0 (at least as things currently stand).
> 	Actually, when I said sd0 or wd0, I was talking about the underlying
> label for the physical disk, not the label which would reside on the
> logical disk presented by the raid.  As such, if my understanding is
> correct, this label should have a partition in it labeld as a "raid" partitio
> n,
> which will start at some block number, and, RF_PROTECTEDSECTORS after that
> block number, will be the beginning of the data area for the raid
> component. 

Correct.

> As you point out, it's a happy coincidence that the bootstrap
> code and the physical disk labels fit inside the RF_PROTECTEDSECTORS region
> of a raid partition which begins at block 0 of a disk.

Happy coincidence, or "64 looks about right" when I picked 64 as the 
magic number.  Hindsight indicates I should have used "62" or "48" 
instead, as i386 boxes tend to have an offset of "63" for the "a" 
partition.  This would have allowed things to overlap *MUCH* easier...
(Stupid i386 BIOS crap.. grumble...)  I suppose it's still not too 
late to change that -- look for a component label at a different spot 
(perhaps the 18K mark of the "reserved area") and if a label is found 
there, assume that RF_PROTECTEDSECTORS is only 48 or something.

This doesn't solve the problem in general for all archs, but it could 
make life much easier for i386... 

> 	Now, here's another question.  When the autoconfigure code is
> detecting raid components, I presume that it uses the physical disklabel to
> find partitions of disks labeled as "raid" partitions. 

Correct.

> Does it also use
> the size of the partition listed in the physical label to determine the
> offset and size of the raid partition,

Yes.

> or does it use a private copy of the
> size information for that raid partition in the component label which goes
> inside that partition?  I would think that it would just use the
> information inside the physical label, but sometimes, things don't work as
> one might expect.
> 
> 	Finally, since it seems my understanding of the layout of the disks
> with raid partitions is correct, I maintain that it is easiest to achieve
> transparency with respect to setting up bootable raid-1 partitions by
> working with installboot, the second stage boot loaders, and sysinst to
> layout disks which have their FFS filesystems begin at an offset compatible
> with Raidframe's RF_PROTECTEDSECTORS constant.  I believe that, by default,
> the superblock of an FFS filesystem begins 16 blocks after the beginning of
> a partition so as to leave room for disklabels and bootstrap dcode.
> Sysinst could be taught to form two partitions on systems which will have
> raid installations:
> 1.  The "non-raie" partition, which would start at RF_PROTECTEDSECTORS
> minus 16.
> 
> 2.  The raid partition itself, which would begin, presumably, at the
> beginning of the disk.  Then, if you told the ROM to boot from sd0a, the "A"
> partition would lign up with your "raid" partition, and all would be well,
> whether or not you were booting with a rooted raid partition, or just
> booting the disk to run as a disk.
> 
> 	I realize that this doesn't cover installations where folks didn't
> realize they wanted a "raid" install from the outset, but do we really need
> to cover that case?  

In an ideal world, yes, but doing so effectively is proving somewhat 
challenging.  So the question becomes "how much work is needed to do 
it, and is that work worth it?".  

Later...

Greg Oster