[ On Wednesday, August 13, 2003 at 18:12:10 (-0700), Brian Buhrow wrote: ]
> Subject: Re: RAIDFrame and NetBSD/sparc booting issues
>
> 	I realize that this doesn't cover installations where folks didn't
> realize they wanted a "raid" install from the outset, but do we really need
> to cover that case?  

Currently I think that's _the_ most important case, hands down (at least
for every platform but alpha IIUC).  All installs and all existing
installed systems start out being unaware of RAIDframe way by default
and as far as I can tell there's no support in any of the "standard"
install procedures for preparing for a RAID-1 configuration.

I.e. I wouldn't describe the "bootstrapping" procedure used to uplift
any existing system onto a second disk with a new partitioning suitable
for RAID-1 and then reconstructing the re-arranged version back to the
first disk as anything more than a bad hack.  There's significant risk
and a lot more overhead to this procedure too, so much so that even
though I have a pretty decent theoretical understanding of it as well as
having the experience of actually doing it a couple of times in real
life, I'm still loathe to try to do it to any existing production system
without first at least planning to do a full system re-install anyway.

The other problem your proposal (and all the existing hacks for the
likes of i386 and sparc) leaves unsolved is the complication of finding
the proper offset and size for the dump partition, especially when a
single RAID-1 volume is used for all the boot disk partitions.

I'd hardly call your proposal "easiest" either.  Your proposal requires
changing a significant number of standard and critical components and as
well as the updating of critical system configurations with settings
that I expect could not be made to be compatible with non-RAIDframe
kernels.

On the other hand moving the RAID-1 component label to the end of the
RAID partition requires only one relatively simple change to one
optional system component and leaves absolutely everything else (well
except for the need to somehow reserve the last 64 sectors) exactly as
it is in a 100% transparent state.  Indeed such a simple change to the
RAIDframe code can be back-ported to existing systems with ease and with
almost zero risk.  The only significant and difficult (and thus risky)
change necessary is to somehow allocate 64 sectors from the end of the
last partition to be included in the RAID-1 set, and
worse-comes-to-worse this can probably even be done with a system
imutable file and a minor hack to fsdb, assuming one can calculate the
block numbers of the sectors to be reserved (something even I would find
easier to do than finding the dump partition offset and size within a
RAID-1 comonent without the use of experimentation.  I.e. it's a LOT
easier to reserve the last 64 sectors in a partition, even one already
in use by a non-full filesystem, than it is to change the offset of that
filesystem.

Your proposal is also certainly very far from being "transparent" with
respect to non-RAID configurations as well.  Transparency in the sense
I've been using the word in this discussion means that everything about
the layout of the primary boot disk and its filesystems, as well as the
way the boot procedure works, all remains 99.99% identical to a non-RAID
configuration with the only significant change happening during the very
last stage of the startup of a RAIDframe capable kernel where the RAID-1
volume is brought to life and the root filesystem is mounted from it
instead of from the physical boot drive (along with the need to reserve
those last 64 sectors which are most likely currently unused anyway).

-- 
						Greg A. Woods

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