Re: migrating to MAXPARTITIONS = 16

[David Laight <david%l8s.co.uk@localhost>]

On Wed, May 18, 2011 at 01:59:38PM +0000, Jonathan A. Kollasch wrote:
> Hi,
> 
> It's not uncommon for me to place a NetBSD/x86 disk in my Orion-based
> NAS.  This fails because NetBSD/x86 has 16 partitions in the disklabel
> and NetBSD/arm only accepts 8.  What do I need to be aware of if/when I
> adjust arm/include/disklabel.h? (Similar to how it was adjusted on i386.)

Last time I looked there were three problems:

1) The size of the disklabel written to disk depends on the architecture,
   not on the disk layout.

2) You can't tell from the disklabel contents whether there are 8 or 16
   partitions.

3) The 'whole disk' partition might be 'c' or 'd'.

4) Disk device minor number mappings (i386 and amd64 differ here).

Some stuff that might help:

1) I think all the disklabels that only support 8 partitions are written
   offset into the disk sector too far to allow 16 partitions.
   This might be the only way to detect the size of the on-disk label.

2) There is a 'number of partitions' field, but it only defines the
   number of used partitions, not the size of the label structure.
   Maybe that could be changed when labels are written back.
   I can't remember where d_checksum ends - perhaps it could be
   used to determine the length?

3) The only place i386/amd64 (and possibly others) use the 'c' partition
   is in the check for overwriting the 'labelsector'.
   You can't do sector read/write using 'c'.
   This means that the kernel could be changed to make 'c' not special,
   and c/d could be flipped between on-disk and kernel.

There is some 'hunt the disklabel' code, I'm not sure how many ports
actually use it - it is more or less generic.
Similarly the code for generating a (in kernel) disklabel from the mbr
is potentially MI.

        David

-- 
David Laight: david%l8s.co.uk@localhost