Date: Thu, 16 Mar 2006 17:18:25 -0800 From: Julian Elischer <julian@elischer.org> To: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Cc: freebsd-current@freebsd.org Subject: Re: [patch] NetBSD disklabel support for geom_bsd Message-ID: <441A0E61.5010707@elischer.org> In-Reply-To: <20060317012428.N52721@atlantis.atlantis.dp.ua> References: <20060317012428.N52721@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?441A0E61.5010707>