Subject: Re: Upgrading OS for an environment using Raid
To: David Laight <email@example.com>
From: Daniel Carosone <firstname.lastname@example.org>
Date: 01/05/2004 07:29:50
Content-Type: text/plain; charset=us-ascii
On Sun, Jan 04, 2004 at 07:17:22PM +0000, David Laight wrote:
> On Fri, Jan 02, 2004 at 02:40:52PM -0600, Frederick Bruckman wrote:
> > though it would be neat if "sysinst" understood RAID.
> That would bloat the install kernels....
It would, and although Greg has recently done quite a lot of work that
has shrunk RF, pressure on the install media is still far too much to
accommodate it, in their present form. That's a separate problem
we're going to have to solve properly soon enough.
Anyway, if you're using RAID1 rather than RAID5, there's another
(arguably even better) option that would be nice to support if we
could. Before upgrading, split the mirror (by detaching the "b"
half), then upgrade directly into the underlying "a" half of the
mirror. This could be booted from and tested, before the second half
is reattached and sync'd - and if the upgrade went badly, the detached
second half used for rollback.
This kind of mechanism is common where the underlying mirroring
mechanism is one that's understood by the install media (or in
hardware), but NetBSD currently lacks the ability to do this easily in
the common case - as far as I can tell for just one reason.
The typical user will create one RAID1 set, and partition
root/usr/var.. inside there. This means there's a second disklabel
offset inside the RAID volume that must be read to find the "halves".
For the special case of RAID1 sets and install media, adding the
ability to find and read this label might be quite
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----