Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Mar 2006 03:18:47 +0200 (EET)
From:      Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
To:        Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no>
Cc:        freebsd-current@freebsd.org
Subject:   Re: [patch] NetBSD disklabel support for geom_bsd
Message-ID:  <20060318025758.U40573@atlantis.atlantis.dp.ua>
In-Reply-To: <86u09x2au9.fsf@xps.des.no>
References:  <20060317012428.N52721@atlantis.atlantis.dp.ua> <863bhh3y05.fsf@xps.des.no> <20060317194142.C90888@atlantis.atlantis.dp.ua> <86u09x2au9.fsf@xps.des.no>

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

Hello!

On Fri, 17 Mar 2006, Dag-Erling Sm?rgrav wrote:
>> media offsets in the entries of this label are not slice-relative
>> like ours, but absolute media offsets instead, and thus can point
>> _outside_ NetBSD slice! Their partitions can thus be aliases for our
>> slice devices.
>
> Yes.  The offsets in our disklabels used to be device-relative too.

  I must admit my error regarding media offsets in FreeBSD disklabels.
They actually absolute media offsets, just like in NetBSD. My patch
works correctly only due to the unusially intellectual code in g_bsd_modify()
which starts with the comment /* Historical braindamage... */. It
understands correctly both absolute and relative offsets. Now
the only valid point in step (2) of my patch is removing partition entries
which point outside provider. I still think that it's too dangerous
to have ad0s3e device which actually isn't part of ad0s3, but is an
alias for ad0s1 instead. And I think that we can remove such alias
entries regardless of partition type (not only for NetBSD slices).

> It is still possible to create dangerously dedicated disks, btw, and
> it is still possible to put a disklabel (or even a filesystem)
> directly on a device.  GEOM means *more* freedom, not less.

  I've never said the contrary. I'm analyzing particular case: NetBSD
disklabel on sliced media. For the sliceless case, my patch will
essentially be NOOP, since there will be no entry which will point outside
it's provider.

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?20060318025758.U40573>