From owner-freebsd-geom@FreeBSD.ORG Sat Sep 4 17:46:52 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03F0016A4CE for ; Sat, 4 Sep 2004 17:46:52 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-161-125.dclient.hispeed.ch [80.219.161.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E53943D39 for ; Sat, 4 Sep 2004 17:46:50 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a17d:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i84Hkh401007 verified NO) for ; Sat, 4 Sep 2004 19:46:47 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i84HkgQ01006; Sat, 4 Sep 2004 19:46:42 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 4 Sep 2004 19:46:42 +0200 (CEST) Message-Id: <200409041746.i84HkgQ01006@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200408142223.i7EMNdY00919@Mail.NOSPAM.DynDNS.dK> <20040815184030.GD21307@afields.ca> <1092597931.18338.25.camel@zappa.Chelsea-Ct.Org> To: freebsd-geom@freebsd.org Subject: Re: GEOM and NetBSD compatibility question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 17:46:52 -0000 [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