On Wed, Nov 15, 2006 at 04:45:02PM -0700, Lori Alt wrote: > 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.
OK, thanks for the clarification. "Optional" sounds good to me,
whatever the default may be.
And thanks again for working on the monster :)
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
pgpVyMEDYPq4k.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
