From owner-freebsd-hackers  Sat Nov  2 21:26:30 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA24165
          for hackers-outgoing; Sat, 2 Nov 1996 21:26:30 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA24160
          for <freebsd-hackers@FreeBSD.org>; Sat, 2 Nov 1996 21:26:25 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id QAA10739; Sun, 3 Nov 1996 16:25:21 +1100
Date: Sun, 3 Nov 1996 16:25:21 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199611030525.QAA10739@godzilla.zeta.org.au>
To: imp@village.org, joerg_wunsch@uriah.heep.sax.de
Subject: Re: Blargh - BSDI disk labels
Cc: freebsd-hackers@FreeBSD.org, karl@Mcs.Net
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>: Do they perchance already use 16 partitions instead of 8?
>
>Speaking of which, does anybody here know of any changes to the
>NetBSD/OpenBSD base that would preclude FreeBSD from being able to
>mount those disks?  I know of the disk label problem (in OpenBSD at
>least), which should be relatively easy to fix, but are there others?

The disklabel "struct" is of variable size, so ones written with a
larger in-core size should just work, provided no more than 8 partitions
are actually used.  (The checksum only covers the partitions that are
used.  There is a problem searching for labels at nonzero offsets in
the label sector, but such labels are probably very rare.)

This is a reason not to pad out the number of partitions in the `auto'
label to the maximum - it the maximum is 16, and 16 are used, with 8
null ones at the end, then portability to systems with a maximum of 8
is broken unnecessarily.  The `auto' label is supposed to give the
maximum, but this is broken - it actually gives 3.

Bruce