[patch] NetBSD disklabel support for geom_bsd
Julian Elischer
julian at elischer.org
Fri Mar 17 01:18:27 UTC 2006
Dmitry Pryanishnikov wrote:
>
> 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.
why not make a completely separate type and allow access to all teh
slices with the
same partition letters that netBSD uses.. i.e. a g_nbsd type..
>
> Sincerely, Dmitry
More information about the freebsd-current
mailing list