Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Mar 2006 02:34:54 +0200 (EET)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        freebsd-current@freebsd.org
Subject:   [patch] NetBSD disklabel support for geom_bsd
Message-ID:  <20060317012428.N52721@atlantis.atlantis.dp.ua>

next in thread | raw e-mail | index | archive | help

Hello!

   I've installed NetBSD 3.0 recently on the same HDD with FreeBSD-CURRENT
and found that OSes just don't see each other's partitions. I thought
that it would be convenient for FreeBSD developers if FreeBSD were able
to understand NetBSD's disklabel as we borrow their code occasionally ;)
After detailed analysis I understood the difference between disklabel formats:
they are essentially the same except 2 points:

1) NetBSD people extended partition table to 16 entries vs. our 8. That's OK,
    we have place for 22 entries within 512-byte sector for disklabel offset 0,
    and 18 for offset 64 bytes (Alpha's case).

2) (most important) NetBSD disklabel describes partitions not slice-relative
    (like ours), but the whole device-relative. They have no slice devices, so
    their disklabel actually duplicates functionality of device slice
    table, and describes both NetBSD partitions and other slices as partitions.
    E.g., for my HDD I've got the following NetBSD disklabel:

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
  a:   2097648 147942585     4.2BSD   2048 16384 21872
  b:   2097648 150040233       swap
  c:  81931500 147942585     unused      0     0
  d: 312579695         0     unused      0     0
  e:   2088387        63      MSDOS
  f:  61440624 152137881     4.2BSD   2048 16384 28704
  g:  10150560 213578505     4.2BSD   2048 16384 28456

   and so on.

    So, from the FreeBSD's POV the only useful information from NetBSD
disklabel are the entries which point within NetBSD slice (in my example,
a-c,f,g). Others already have FreeBSD's counterparts (my NetBSD slice
is ad0s3, but partition 'd' describes the whole ad0, and 'e' == ad0s1),
and it would be wrong and even dangerous to keep them.

  I've created simple patches against geom_bsd.c for CURRENT and RELENG_6:

 	ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/CURRENT.diff
 	ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/RELENG_6.diff

which implement recognition of NetBSD disklabel only on slicer level
(no support for ioctls == no support for bsdlabel), but IMHO that's
enough - rest can be done from the NetBSD itself. My patches are quite
simple:

1. g_bsd_try() modified to accept large (>8) number of partitions;

2. g_bsd_taste() accepts NetBSD's slice type 169 and does special
    processing for it: truncates partition table to 8 entries,
    converts offsets from absolute to slice-relative, and removes
    entries which describe areas outside the NetBSD slice.

I have verified these patches against 2 different NetBSD partition
layouts, they work as expected (for the shown case, create ad0s3a-c,
ad0s3f-g). The only drawback in my solution is that only first 8 partitions
(of currently 16 NetBSD's) can be represented. If you'll create separate
/, /usr, /var, /home and user-defined partition during NetBSD install,
they'll be: 'a', 'f', 'g', 'h' and 'm' for my HDD layout, and 'm' will
be unreachable from the FreeBSD. I could remap it to the free slot
(e.g. 'd'), but I've decided not to do it, because it could add confusion
IMHO. After all, both slices (FreeBSD and NetBSD) are usually managed
by the same person, so [s]he'll create reasonable NetBSD partition
layout.

  I hope my patch can be useful, and would like to get feedback about it.

Sincerely, Dmitry
-- 
Atlantis ISP, System Administrator
e-mail:  dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060317012428.N52721>