Greg Oster wrote:
> jakllsch@kollasch.net writes:
>   
>
>> Also, do we want the RAIDframe header at the beginning of the
>> partition still? 
>>     
>
> Personally, I'd still like to see the component label bits live in a 
> separate partition (e.g. a "RAID metadata partition" that contains 
> component labels for all RAID entities on that particular device..)
>   

Have you given any thought to what you'd like this to look like?  I'm in
the midst of playing around with various GPT-related things, and while
my initial instinct was just to make a partition type akin to the RAID
disklabel type, if you've got ideas how things might be made better or
more flexible, I'd like to hear them.  There's also enough types
available :)  that changing this later probably wouldn't be that hard...
>   
>> (Probably too late to change this.)
>>     
>
> Not in my books :)  If nothing else, being able to specify a GPT ID 
> for components would be useful for RAIDframe... (they'd make figuring 
> out what components belong to what RAID sets a little bit easier..)
>   

Yes, I think we need at least one component type.  I also agree it's not
to late to extend things...

>   
>> You know first hand how GRUB doesn't deal with this well. (Thanks
>> for the howto BTW.) The EFI/GPT spec explicitly forbids overlapping
>> partitions (s. 11.2.2.1), which is the abstract solution we've
>> used to get around this so far.  I suppose we could put the 64
>> raidframe sectors in their own partition immediately preceding
>> a RAID-1 area. That or explicitly teach GRUB (v2) about raidframe.
>> Dunno, just brainstorming here.
>>     
>
> While there are 64 reserved sectors, there is currently only a single 
> 512-byte sector used to contain the component label.  Where that 
> sector lives doesn't really matter a whole bunch, as long as we can 
> locate it and associate it with a particular partition (which GPT 
> should make much easier...)
>
> The trick here is to design something that works, provide some sort 
> of upgrade path, and still remain backwards compatible with existing 
> RAIDframe setups...  My gut reaction is that shouldn't be too hard to 
> do... 
>
>   

I would tend to agree here.

+j