Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/raidframe

I think the most important thing is that people who have a system that
boots now (and aren't doing anything super sick) should continue to have
that system boot after they just replace the kernel.  And we should
discuss how to do this before the change is committed :-)

> On Apr 2, 10:33am, (Greg Troxel) wrote:
> -- Subject: Re: CVS commit: src/sys/dev/raidframe
> | It seems there are 3 behaviors for root
> | 
> |   1) don't change the root device (old behavior with -A yes)
> That does autoconfig for raid and does not deal with root at all.

Right, but it is a way that some systems might be set up now.

> |   2) if root is on a component, change root to the raid, otherwise don't
> |   change.
> This behavior did not exist before my commit. It is now only turned on with
> -A root. 
> |   3) force the root device to be the raid (old behavior with -A root)
> This does not exist anymore. You can currently:
>     1. boot -a
>     2. make a kernel that has root on raidx

so this is the real concern, that the straightforward update will make
systems unbootable.

> Or:
>     1. add the ability to pass the root name through the bootblocks/userconf
>     2. add a raidctl -A forceroot and obey that.
> | It seems to me that the behavior 1 (not in case 2) isn't useful, and
> | that we could make behavior 2 the default behavior, with 3 with -A yes.
> Yes, I think you are right. There could be an issue with having wd0a being
> the real root and then a raid component on wd0e... In that case do we want
> to make wd0e the root device because it is on the same drive?

I don't think so.  The case that matters for automatically making the
raid root is when one has a RAID1 and the bootblocks boot off of half of
it.   So I think the narrow "if the boot device is a component of an
autoconfigured raid, switch the boot device to that raid" really is what
we want to do.

> | Is there any reason why someone would not want to use the raid for root
> | when a) the system booted from a component and b) it's marked
> | autoconfigurable?  If anything, I think there should be a way to disable
> | autoconfiguration.
> See above... There is a way to disable autoconfiguration, but there is
> currently no easy way to get the old behavior? What do you think we should
> do?

I guess the idea that you boot from half a raid and then you use root on
that half - doesn't make sense.  That breaks the raid set.  I think
people either set things up as (typical examples) one of the following

  boot a kernel from wd0a, which is nonraid, and have a RAID1 on
  wd0e/wd1e marked -A root.  Here, wd0a is merely as a rescue partition
  and a way to load the kernel.  This is what you used to have to do
  before RAID1 boot support, which means I think you still do have to do
  it on some platforms.

  have wd0a/wd1a be a RAID1.  Boot from wd0a (or wd1a) with boot blocks
  that skip over the raid header, and then -A root is used to make that
  the root device.

So the first way needs -A root to keep its current semantics.   The 2nd
way works with -A root, but I think it's fine to make it work with
merely -A yes.

Attachment: pgpO4ZB0xw6IF.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index