Subject: Re: GPT guids
To: None <firstname.lastname@example.org>
From: Greg Oster <email@example.com>
Date: 12/17/2007 09:55:24
> On Sun, Dec 16, 2007 at 05:44:53PM -0800, Jeff Rizzo wrote:
> > firstname.lastname@example.org 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.
> > >
> > I agree with this.
> 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. 18.104.22.168), 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