[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: migrating to MAXPARTITIONS = 16
On Wed, May 18, 2011 at 01:59:38PM +0000, Jonathan A. Kollasch wrote:
> 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
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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |