Luke Mewburn <lukem@wasabisystems.com> writes:

Hi,

> I've fixed mbrlabel to be a lot saner about updating the disk label.

> Now it won't actually update the disk label (in-core or on-disk)
> unless `-f' is given.

> It's also a *lot* smarter about how it works; existing entries in the
> NetBSD disk label will remain untouched, and mbrlabel will only add
> entries to the disklabel for MBR partitions which don't have the same
> size and offset as an existing partition slot in the disk label.

Very nice. However, this brings up the old favourite issue of what to
do about the limitation of 8 partitions in the i386 label. As an
example I show the output from the new mbrlabel when run on my 20GB
laptop disk. Note that there are several detected partitions that
cannot be part of the label because there are "no slots".

I use W98 divided into two partitions (C: and D:, I install new stuff
in D: with the hope that it'll survive the occational reinstalls on C:
when W98 gets munged). Then there is a Linux also divided into two
partitions and finally NetBSD with as much flexibility partition wise
as is left.

How much is that? Well, out of 8 you lose three immediately (swap, c
and d). Five to go. Windows needs two and Linux two which leaves me
with my primary OS crammed into one partition of 13GB. Won't work. I
sacrificed access to D: to get me another partition, so now I have the
entire "stock NetBSD" in / and everything else (/usr/local, /usr/pkg,
/usr/src, /usr/home, etc) bunched together in a giant /usr/store. This
is clearly not an ideal partitioning scheme.

This question of the maximum number of has been discussed several
times previously and each time it seems to stumble upon the search for
the final solution (since it is rather painful to switch label format
repeatedly). After thinking about it for a while I reached the
conclusion that

a) 8 partitions for disks that before next Christmas will often be
   larger than 100GB is clearly insufficient. Especially since several
   partitions often are lost to various system uses immediately.

b) even with future giant disks of gazillions of bytes I see no
   automatic need for a tremendous number of partitions. On the
   contrary, the partitioning I want today on the 46GB disk (on
   another machine) is quite similar to what I created for a Sun on a
   1.3GB disk five years ago. It is also quite similar to what I used
   on an old 4.3BSD VAX with 80MB even further back.

The reason for this is (I think) that as disks grow the size of files
grow somewhat, but much more importantly the size of packages
grow. Today a package that requires more than 1 GB is still rather
large but not unheard of. In two years time they will be common.

Therefore I strongly suggest that the maximum number of partitions is
increased to what is easily implemented, which seems to be 16 (or is
it as simple to go to MAXMAXPARTITIONS (i.e. 22)?). If it technically
possible I'd vote for 17 as a nice arbitrary number ;-)

And be done with it.

I don't see a driving need for numbers much larger than that. And
based upon the observation above I don't think there will be a need in
the forseeable future that motivate a quest for the ultimate scalable
solution. Especially not if such a quest takes several years.

Johan

---------
Found MSDOS partition at 63, size 4188177
  skipping existing MSDOS partition at slot h.
Found 4.2BSD partition at 12564594, size 23034974
  skipping existing unused partition at slot c.
Found Linux Ext2 partition at 35599568, size 3470512
  skipping existing Linux Ext2 partition at slot f.
Found Linux Ext2 partition at 4188303, size 272097
  WARNING: no slots free for Linux Ext2 partition.
Found swap partition at 4460463, size 211617
  WARNING: no slots free for swap partition.
Found MSDOS partition at 4672143, size 7877457
  WARNING: no slots free for MSDOS partition.

8 partitions:
#        size   offset     fstype   [fsize bsize cpg/sgs]
  a:  3072000 12564594     4.2BSD     1024  8192    16   # (Cyl. 12464*- 15512*)
  b:   442260 15636594       swap                        # (Cyl. 15512*- 15951*)
  c: 23034974 12564594     unused        0     0         # (Cyl. 12464*- 35317*)
  d: 39070080        0     unused        0     0         # (Cyl.    0 - 38759)
  e: 19520714 16078854     4.2BSD     1024  8192    16   # (Cyl. 15951*- 35317*)
  f:  3470512 35599568 Linux Ext2     1024  8192         # (Cyl. 35317*- 38759)
  g:   272096  4188303 Linux Ext2     1024  8192         # (Cyl. 4155*- 4424*)
  h:  4188177       63      MSDOS                        # (Cyl.    0*- 4154)

Not updating disk label.