Ceri Davies wrote:
On Tue, Nov 14, 2006 at 07:32:08PM +0100, [EMAIL PROTECTED] wrote:
Actually, we have considered this. On both SPARC and x86, there will be
a way to specify the root file system (i.e., the bootable dataset) to be
booted,
at either the GRUB prompt (for x86) or the OBP prompt (for SPARC).
If no root file system is specified, the current default 'bootfs' specified
in the root pool's metadata will be booted. But it will be possible to
override the default, which will provide that "fallback" boot capability.
I was thinking of some automated mechanism such as:
- BIOS which, when reset during POST, will switch to safe
defaults and enter setup
- Windows which, when reset during boot, will offer safe mode
at the next boot.
I was thinking of something that on activation of a new boot environment
would automatically fallback on catastrophic failure.
I don't wish to sound ungrateful or unconstructive but there's no other
way to say this: I liked ZFS better when it was a filesystem + volume
manager rather than the one-tool-fits-all monster that it seems to be
heading in.
I'm very concerned about bolting some flavour of boot loader on to the
side, particularly one that's automatic. I'm not doubting that the
concept is way cool, but I want predictable behaviour every time; not
way cool.
All of these ideas about automated recovery are just ideas. I don't think
we've reached monsterdom just yet. For right now, the planned behavior
is more predictable: there is one dataset specified as the 'default
bootable
dataset' for the pool. You will have to take explicit action (something
like luactivate) to change that default. You will always have a failsafe
archive to boot if something goes terribly wrong and you need to
fix your menu.lst or set a different default bootable dataset. You will
also be able to have multiple entries in the menu.list file, corresponding
to multiple BEs, but that will be optional.
But I'm open to these ideas of automatic recovery. It's an interesting
thing to consider. Ultimately, it might need to be something that is
optional, so that we could also get behavior that is more predictable.
Lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
