Subject: Re: RAIDFrame and NetBSD/sparc booting issues
To: NetBSD/sparc Discussion List <port-sparc@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 08/11/2003 16:05:02
[ On Monday, August 11, 2003 at 11:08:12 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: RAIDFrame and NetBSD/sparc booting issues
>
> I've only one sparc running with raid. I did a hugly hack: I made
> sd0a (and sd1a) match the raid0a partition. This mean that I can mount
> the root partition with 3 different ways: raid0a, sd0a and sd1a.
> Of course you have to be very carefull not mounting more than one
> R/W !

I wouldn't call that any kind of hack -- that's exactly what I would
expect to have to do to make a RAID-1 root filesystem work properly if
the system firmware and/or OS boot blocks don't fully support booting
from a RAID.  I've always wondered why this isn't the way it was always
done right from the beginning, at least for RAID-1 volumes.

In fact I've been trying to figure out exactly how to do this for my own
sparcs given the current limitations in how RAIDframe layout works.  I
was stuck on trying to figure out whether I could make the root/boot
filesystem start at a non-zero offset on these machines or not and I
hadn't had time yet to experiment.

Your example paves the way!  Thanks!

I notice though that you have different sizes for sd0b and raid0b.  Was
this intentional, and if so, why?

Also, is there currently any way for RAIDframe to notice, say from the
fs_time in the superblock vs. some timestamp in its own component
labels, that one of the filesystem copies had been used directly more
recently than the combined RAID-1 filesystem and thus be able to figure
out which component is out of date and needs reconstructing?  If this
would work is there any code which would implement it?  It seems to me
this would require RAIDframe to know something of the internal structure
of the filesystems contained in it's logical volume partitions, but in
general I don't see why this would be too difficult to achieve.


> This hack works, but you have to really understand what you're doing with the
> offsets.

Yes, I'd say that's the only part that's hackish in some sense at the
moment.

It would be nice if RAIDframe would place its component label just
inside the end of the partition instead of at the beginning, always
reserving exactly one track of the physical partition to use for this
purpose (at least I think it makes more sense to always reserve a whole
track instead of some arbitrary number like 64 sectors).  This way one
could simply subtract a track's worth of sectors from the size of the
last matching "plain" partition on each component (and optionally create
mini one-track partition entries to document the reserved the space for
the RAIDframe component labels).  This way the offset and size of each
actual filesystem partition, both those inside the RAID-1 volume and
those for each "plain" partition on each physical component volume,
would be identical regardless of whether the mirror was in use or not,
or even if it had yet been created.  This way it would be nearly trivial
to create a mirror of any existing boot drive for any kind of platform
(having only to adjust the size of the "last" paritition if there wasn't
already a track's worth of spare sectors following it).

Greg do you have any comment on how hard it would be to modify RAIDframe
to do this, at least for RAID-1 volumes, and whether or not you think it
makes sense?

Could this be done in a backwards compatible way as well?

-- 
						Greg A. Woods

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