RE: partition minor numbering wrong with GPT

[Matt_Domsch]

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

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

The kernel certainly does, skipping empty entries.

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

--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001!