Re: GPT guids

jakllschkollasch.net writes:
> On Sun, Dec 16, 2007 at 05:44:53PM -0800, Jeff Rizzo
wrote:
> > jakllschkollasch.net wrote:
> > > Also, I believe we need to think more about
RAIDframe,
> > > EFI booting and BIOS booting.  (Yes, the
latter is possible.)
> > > Xen domUs present some of the same
interestingness.
> > >
> >=20
> > I agree with this.
> >=20
> 
> Well, mostly do we want GPT partition tables within a
RAID-1 area?

Why not?  (e.g. for RAID sets composed of other RAID
sets...)

> Or do we want a raid(4) (RAID-1) device for each
separate GPT partition?

I'm not sure what you mean by this..
 
> 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..)

> (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..)

> 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... 

Later...

Greg Oster

Greg Oster wrote:
> jakllschkollasch.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