[ On Tuesday, December 7, 2004 at 12:04:43 (+1100), matthew green wrote: ]
> Subject: re: sysinst problems 
>
> raidframe is one reason to use overlapping disklabels.  i've in the
> past done this so that i can access the in-raid filesystem on a kernel
> that was lacking raidframe support...

Hmmm....  well that's not something sysinst needs to support (yet)

However it is a very good reason to have the ability to specify
additional overlapping paritions other than the whole-disk
partitions(s) -- just not in sysinst, at least not until sysinst knows
how to support RAIDframe :-)

> i've also setup dumps directly to this partition, rather than via the
> raidframe device.  then savecore finds it in swap like normal...

(don't you mean "savecore finds it in the dump partition"?  savecore
does look for _dumpdev in the kernel....  and of course savecore must
also finish before raidframeparity starts....)

I'm not so sure overlapping partition entries are the best solution to
this need....  but I don't see an obvious _easy_ alternative either.

I think this kind of overlapping swap/dump partition could be something
that "sysinst" would create automatically if it were to have built-in
support for creating and/or upgrading systems using RAIDframe mirroring.
It could even be allowed for "raw" access to the mirrored filesystem
within a RAID partition.  I.e. if the user instructs "use existing" then
sysinst could alow a partition with fstype==swap or fstype==4.2BSD to
overlap a partition with fstype==RAID, IFF the offsets and sizes jived
with what works, but not otherwise.

After all the kernel also needs to know the rule about how to find the
"raw" dump partition....


As for not-so-easy alternatives....

In theory it would be nice if RAIDframe RAID-1 worked without requiring
the RAIDframe info to occupy any noticable space at the beginning of the
partition and thus forcing the filesystem to be offset from the
beginning of the partition (perhaps it could be stored at the end,
though somehow the "size" must accomodate) -- then RAID-1 mirrored
devices could be accessed transparently without RAIDframe -- even from
any other OS that understood the FFS layout and the basic old-fashioned
partition label.

Alternately maybe once we have devfs or similar the disk driver could
automatically set up device nodes that point to the filesystem inside a
RAID-1 mirrored device and also manage the interlock between those nodes
and the raidNX nodes too.  That doesn't necessarily solve the "access
without RAIDframe" need though, nor does it even come close to any
solution to the problem of access from a foreign OS that doesn't know
about all the NetBSD specific RAIDframe rules.

I seem to remember discussing these RAID-1 vs. swap/dump/internal-FS
things sometime in the past at least once before too....  :-)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>