Re: partition minor numbering wrong with GPT

[Andrew Clausen]

On Tue, Mar 19, 2002 at 03:20:47PM -0600, address@hidden wrote:
> > If I then "rm 2", parted thinks the minors are 1,3 and 4, but 
> > the kernel
> > thinks they are 1,2 and 3.  That is real bad news, I think.
> 
> You're right, this probably isn't optimal.
> Looking at the kernel code (and trying to clean up this and the endianness
> stuff), the kernel allows for various numbers of partitions per device,
> based on struct gendisk->minor_shift - 1.  For IDE, that's 63, for SCSI, 15.
> GPT allows for a minimum of 128 entries, with as many more as you might
> need.
> 
> So, I took the approach of adding all non-deleted partition entries as
> actual partitions to the kernel.  This lets you have 15 non-deleted
> partitions scattered anywhere within the 128 possible entries, and the first
> 15 get used.
> 
> I can certainly see the rational behind making only the first 15 entries,
> regardless of whether they're zero'd or not, be used by the kernel.

In future, we'll probably be getting a lot more than 15...

> Things
> like /dev/sda7 doesn't change if /dev/sda6 is deleted.  But, that's also why
> file system GUIDs, labels, and partition GUIDs and labels exist.  In a sane
> world, you'd always mount by label.  But we're not there yet.

Agreed.  OTOH, there is something to be said for being able to
address a device by it's location (as well as it's ID/name/whatever).
But, the name probably could serve equally well.

I guess this means parted should accept partition names instead
of numbers...?

> > I'm assuming everything orders partitions by the order on the 
> > partition
> > table entries, and not the phyiscal order of th partitions on 
> > disk, but I havn't verified that.

Right.

> So, while I'm mucking about with this in the kernel, what's the best
> solution for consistency?

I think changing the kernel gpt code to match everything else...
It's nasty that deleting a partition means you have to redo
/etc/fstab.

Andrew