Date: Sat, 4 Sep 2004 19:46:42 +0200 (CEST) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: freebsd-geom@freebsd.org Subject: Re: GEOM and NetBSD compatibility question Message-ID: <200409041746.i84HkgQ01006@Mail.NOSPAM.DynDNS.dK> References: <200408142223.i7EMNdY00919@Mail.NOSPAM.DynDNS.dK> <20040815184030.GD21307@afields.ca> <1092597931.18338.25.camel@zappa.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
[as usual, sorry for the delay in this reply, and as usual,
keep replies to the list and I'll catch up later, thanks]
Allan Fields wrote:
> > a solution, and now I'm experiencing this again when trying to
> > use my NetBSD partition under FreeBSD-CURRENT and GEOM.
> Which, all things considered, isn't an entirely outlandish proposition.
Works fine with 4.whatever...
$ mount
[ ... ]
/dev/da0s1a on /DragonFly (ufs, local, read-only)
/dev/da0s1g on /DragonFly/usr (ufs, local, read-only)
/dev/da0s1f on /DragonFly/var (ufs, local, read-only)
/dev/da0s2a on /NetBSD (ufs, local, read-only)
/dev/da0s2e on /NetBSD/usr (ufs, local, read-only)
/dev/da0s2f on /NetBSD/var (ufs, local, read-only)
/dev/da0s3a on /FreeBSD-CURRENT (ufs, local, read-only)
/dev/da0s3e on /FreeBSD-CURRENT/usr (ufs, local, read-only)
/dev/da0s3f on /FreeBSD-CURRENT/var (ufs, local, read-only)
[ ... ]
No problem changing the mounts to read-write. I keep as much
as possible read-only in order to reduce time in `fsck' after
the inevitable panic.
> > I've applied a hack (first proposed a couple years back) which
> > allows GEOM to recognize the NetBSD ID. However, GEOM is getting
> Can you email the patch (and/or post url to list)?
I'll post it here as it's trivial. The entire extent of my hacks
to GEOM source at the moment is as follows [cut-n-pasted so tab
damage is the result] :
cat /dist/src/FreeBSD6-src/source-hacks/sys/geom/geom_bsd.c-patch
--- geom_bsd.c-ORIG Sat Feb 14 18:59:44 2004
+++ geom_bsd.c Tue May 11 18:56:01 2004
@@ -513,7 +513,8 @@
*/
error = g_getattr("MBR::type", cp, &i);
if (!error) {
- if (i != 165 && flags == G_TF_NORMAL)
+ /* if (i != 165 && flags == G_TF_NORMAL) */
+ if (i != 165 && i != 169 && flags == G_TF_NORMAL)
break;
error = g_getattr("MBR::offset", cp, &ms->mbroffset);
if (error)
This does little more than allow FreeBSD to treat NetBSD ID
as one of its own. Without this, nothing shows up at all.
> I think it should be possible to access both NetBSD and OpenBSD
> labels/partitions from FreeBSD as GEOM is designed to accommodate
> such layouts.
Note too that my systems have all been built from FreeBSD-4,
then changing the ID to 169, and I use the lowest common
denominator of UFS1 filesystems everywhere.
> out. All of the BSDs have diverged on disklabel support. Even
> DragonFly now has some differences in how it handles labels (while
> FreeBSD can currently read them still(?) it doesn't work the other
> way around from my experience).
Hm? This is news to me, as I've just installed DFly (cross-built
under FreeBSD-4) into a disk created under FBSD-4, and I don't
remember any problems accessing anything. (Unless I didn't mount
anything else yet; need to check that) And indeed, I have no
problem accessing DFly from FBSD-4 and vice versa. (There may be
a long-standing hack I've had in FBSD-3/4 that allows this which
is present in DFly and NetBSD -- can't say for sure.) I'm not
sure what problems you may have had, but I have none so far.
> > Here's what GEOM has to say about the NetBSD partition of my
> > disk:
> Can you fill this out as to which slices are which:
> s1: FreeBSD
> s2: NetBSD?
> s3: ?
> s4: ?
> Or is the important point that s2 is the NetBSD label?
Yeah, the most important thing is that s2 is devoted to NetBSD,
but here's my `mount -F' fstab entry as seen from a FBSD-4
system, just so you know what I've put where and what I intend
to do with everything:
## CVSup disk
/dev/da0s1e /mnt ufs ro 0 0
## work directories
/dev/da0s4e /work ufs ro 0 0
## source
/dev/da0s4f /stand ufs ro 0 0
## obj dirs and hacks
/dev/da0s4g /stand/obj ufs ro 0 0
## WAV and ogg files
/dev/da0s4h /cdrom ufs ro 0 0
## Home directories
# /dev/da0s1h /usr/home ufs ro 0 0
## New DragonFlyBSD
/dev/da0s1a /DragonFly ufs ro 0 0
/dev/da0s1g /DragonFly/usr ufs ro 0 0
/dev/da0s1f /DragonFly/var ufs ro 0 0
## NetBSD partition
/dev/da0s2a /NetBSD ufs ro 0 0
/dev/da0s2e /NetBSD/usr ufs ro 0 0
/dev/da0s2f /NetBSD/var ufs ro 0 0
## Another FreeBSD partition -CURRENT
/dev/da0s3a /FreeBSD-CURRENT ufs ro 0 0
/dev/da0s3e /FreeBSD-CURRENT/usr ufs ro 0 0
/dev/da0s3f /FreeBSD-CURRENT/var ufs ro 0 0
s1, s3, and s4 have IDs 165; in order for NetBSD to see itself,
s2 has ID 169.
Now, as seen under FreeBSD-4, the NetBSD partition `disklabel'
command is uninformative as it rejects those partitions which
aren't within what it feels should be the limits. Seen under
NetBSD, those partitions become visible again and allow me to
access parts of the disk outside the boundaries of the NetBSD
DOS-partition ID, which otherwise don't exist.
Under my FreeBSD-4 (slightly modified):
16 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 524288 0 4.2BSD 1024 8192 26 # (Cyl. 0 - 32*)
b: 1048576 524288 swap # (Cyl. 32*- 97*)
c: 12578895 0 unused 0 0 # (Cyl. 0 - 782)
e: 9961472 1572864 4.2BSD 2048 16384 102 # (Cyl. 97*- 717*)
f: 1044559 11534336 4.2BSD 2048 16384 106 # (Cyl. 717*- 782*)
As seen by NetBSD-current (the same disk slice):
16 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 524288 100663290 4.2BSD 1024 8192 26 # (Cyl. 6266 - 6298*)
b: 1048576 101187578 swap # (Cyl. 6298*- 6363*)
c: 12578895 100663290 unused 0 0 # (Cyl. 6266 - 7048)
d: 490232832 0 unused 0 0 # (Cyl. 0 - 30515*)
e: 9961472 102236154 4.2BSD 2048 16384 102 # (Cyl. 6363*- 6983*)
f: 1044559 112197626 4.2BSD 2048 16384 106 # (Cyl. 6983*- 7048)
g: 10485760 157266980 4.2BSD 2048 16384 0 # (Cyl. 9789*- 10442*)
h: 20971520 167752740 4.2BSD 2048 16384 0 # (Cyl. 10442*- 11747*)
i: 262144 63 4.2BSD 1024 8192 26 # (Cyl. 0*- 16*)
j: 10485760 65273919 4.2BSD 1024 8192 26 # (Cyl. 4063*- 4715*)
k: 2097152 63176767 4.2BSD 2048 16384 107 # (Cyl. 3932*- 4063*)
l: 24903611 75759679 4.2BSD 2048 16384 102 # (Cyl. 4715*- 6265)
m: 20971520 136295460 4.2BSD 1024 8192 26 # (Cyl. 8484 - 9789*)
n: 62914560 262207 4.2BSD 2048 16384 97 # (Cyl. 16*- 3932*)
o: 524288 113242185 4.2BSD 1024 8192 26 # (Cyl. 7049 - 7081*)
p: 301508572 188724260 4.2BSD 32768 65536 4664 # (Cyl. 11747*- 30515*)
Note that the NetBSD label uses absolute offsets from the
beginning of the disk, while that shown by FBSD4 uses offsets
relative from the beginning of s2. The sizes of a,b,c,e, and
f match; the offset shown in the NetBSD label should correspond
to the byte-offset that my original message giving what GEOM
had to say about the disk quoted.
As the absolute offsets of s2g-s2p above seen in the NetBSD
label are outside the boundaries of s2c, FBSD4 pretends they
don't exist and refuses to display them. This works, as noted,
under NetBSD to give me access to other parts of the disk that
are not in the NetBSD slice.
(I'll assume the g and h partition cpg values mean something
that I don't know. Forget what they are. That might be an
incompatibility I'm overlooking. I've seen no problems
reading from these particular partitions so far.)
> > da0s2 works fine for what would be da0s2a. Years ago when
> > I tried this, the NetBSD swap partition turned out to be
> > translated by GEOM into the NetBSD /usr and as a result,
> > I've been wary of -current until now.
> And I'd also be wary of unsing a NetBSD partition from FreeBSD, at
> this point: it's not -current per se, but the differences in formats.
> Have you looked at the NetBSD disklabel code for anything that
> stands out?
I have no problems with FreeBSD-4, and as I note, I can mount
da0s2 as /NetBSD, but not da0s2a as /NetBSD. I point to the
`start' (seen in my earlier message) that is different between
the two -- even though it should be the same, as it is for the
other s1/3/4 DOS partitions.
> > I had tried a while back to hack in an absolute/relative
> > offset toggle, but never was able to make all of GEOM
> By toggle do you mean it can turn on/off with differing
> disklabel ID or just manually?
I hoped to get GEOM to understand that certain disklabels
(FreeBSD) would be relative, while others (NetBSD) might be
absolute. The trigger seemed to be the `d' partition which
extended beyond the `c' partition boundaries. It wouldn't
be manual or ID-dependent, because it seemed that upon tasting
the label, GEOM seemed to decide which to use, but had no way
to store that information for later access.
As you can see from the numbers I posted earlier, da0s1 and
da0s2 are absolute offsets, while da0s1* are all relative, and
da0s2* are all absolute offsets. However, later accesses all
assume da0s?* to be relative to da0s?
Looking again through the code, it seems that geom_bsd.c has
the concept of a rawoffset which is set to 0 if part of the
disklabel oversteps its bounds, otherwise is what you would
expect. But I can't see that it's used anywhere other than
where it is set. Not that I'm familiar with the code. And
I haven't looked deeply.
And then, Paul Mather clarified:
> > > It's a property of the NetBSD disklabel that the `d' partition
> > > covers the whole disk. Additionally, I use the additional
> > right
> Well, mostly right. I believe most NetBSD ports treat the "c" partition
> as covering the whole disk and only the i386 (and related?) port applies
> this semantic to the "d" partition instead (due to historical
> precedent?).
Probably due to the (unique-to-?) i386 ability to have
several DOS partitions / IDs on a drive. NetBSD itself
does not have the i386-port-specific ability to distinguish
the different DOS partitions. It only recognizes its own
last time I looked into it with detail.
For other Real Architectures without multiple DOS-partitions
and IDs, there's no need to differentiate between the whole
disk and the part of the disk devoted to NetBSD.
In any case, for my i386 machines, the NetBSD `c' partition
should be identical with what FreeBSD would see as `da0s2' in
my case, and `d' would be `da0'.
This is picking at nits, but I believe is the source of the
problems between GEOM relative offsets and the on-disk
absolute offsets -- most likely a dedicated NetBSD disk
would not have this problem. And I suspect that if I were
to manipulate an on-disk disklabel so that da0s1h were to
be physically within the da0s4 boundaries, I'd see the same
sort of problem. (As I note, I do that under NetBSD as a
workaround for my convenience to access non-NetBSD areas)
Once again, I doubt that there are gross incompatibilities
between the on-disk disklabels or filesystems, as I have no
problems accessing any of the filesystems of any other OS
from FreeBSD-4, NetBSD, or DragonFlyBSD (UFS1, of course).
Only the introduction of GEOM a couple years back broke my
access to NetBSD from what-was-then -current. Going back a
few days from that gave me access to NetBSD again. Read-
only access would make me happy; at present I have none at
all, except to da0s2a only when specified as da0s2 where
it works, but obviously I can't do the same for s2b on up.
thanks
barry bouwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409041746.i84HkgQ01006>