zfs discuss - Nov 2006 - Thoughts on patching + zfs root

Anxiously anticipating the ability to boot off zfs, I know there''s been
some talk about leveraging some of the snapshotting/cloning features in
conjunction with upgrades and patches.

What I am really hoping for is the ability to clone /, patch the clone, then
boot off the clone (by doing a clone swap).  This would minimize the downtime
needed to patch (as compared to today) since the install could be done while the
system is still up and running.  I suspect to do this might require some
interaction with things like patchadd, etc., so I am curious if such a feature
is already in the works, or if perhaps an RFE should be filed.

Assuming the plans are already there for this, I''d like to anticipate
any gotchas with our standard install procedure, and was just wondering if any
thought had been put in as to what the requirements would be.  Just off the top
of my head, I would guess it''d mostly revolve around making sure stuff
is separated properly into different filesystems, but was curious if anyone else
has thought about this.
 
 
This message posted from opensolaris.org

Jason King wrote:
> Anxiously anticipating the ability to boot off zfs, I know there''s
been some talk about leveraging some of the snapshotting/cloning features in
conjunction with upgrades and patches.
>
> What I am really hoping for is the ability to clone /, patch the clone,
then boot off the clone (by doing a clone swap).

I''m pretty sure we already have what you are looking for. Check out
Live
Upgrade on docs.sun.com.

Torrey McMahon wrote:
> Jason King wrote:
>> Anxiously anticipating the ability to boot off zfs, I know
there''s
>> been some talk about leveraging some of the snapshotting/cloning 
>> features in conjunction with upgrades and patches.
>>
>> What I am really hoping for is the ability to clone /, patch the 
>> clone, then boot off the clone (by doing a clone swap).  
>
> I''m pretty sure we already have what you are looking for. Check
out
> Live Upgrade on docs.sun.com.
Right now, liveupgrade makes lots of assumptions about boot environments
being in ufs file systems, but fixing that is part of the zfs-boot 
plan.  So yes, the kinds
of things you can do with liveupgrade, such as cloning environments and then
patching or upgrading them, and then activating them, will be possible with
zfs bootable environments (and will be a lot faster and easier, since 
cloning will be
almost instantaneous and will not require a preallocated slice). 

I''m not sure what will turn out to be a "gotcha" for you, so
let me just
describe
the basics of how zfs booting will work.  Some storage pools will be 
designated
as "root pools", which means that they contain at least one dataset
that
contains
a bootable root file system.  There will be some restrictions on root pools
(the only allowed configuration is an n-way mirror of single disks or 
slices,
each of which must be accessible from the boot prom or BIOS), so best
practice will be to keep data (such as database tables) in a pool separate
from the root pool.  (The separation isn''t required but will probably
turn
out to be best for ease of management.) 

Some datasets will be designated as "bootable", which means that they 
contain
a root file system.  A bootable environment (BE, in LiveUpgrade terminology)
can consist of several datasets, exactly one of which is "bootable".
For example, it will be desirable in many cases to put each zone root in a
separate dataset.  Each of those zone root datasets will be subordinate to a
"bootable" dataset which contains the root of the BE.   Cloning a BE
means
cloning each dataset in the BE.

We in the zfs-boot project owe the community more information about
how the work is progressing.  I hope we can get more of that information
out fairly soon.

Lori

Lori Alt wrote:
> Torrey McMahon wrote:
>> Jason King wrote:
>>> Anxiously anticipating the ability to boot off zfs, I know
there''s
>>> been some talk about leveraging some of the snapshotting/cloning 
>>> features in conjunction with upgrades and patches.
>>>
>>> What I am really hoping for is the ability to clone /, patch the 
>>> clone, then boot off the clone (by doing a clone swap).  
>>
>> I''m pretty sure we already have what you are looking for.
Check out
>> Live Upgrade on docs.sun.com.
> Right now, liveupgrade makes lots of assumptions about boot environments
> being in ufs file systems, but fixing that is part of the zfs-boot 
> plan.  So yes, the kinds
> of things you can do with liveupgrade, such as cloning environments and 
> then
> patching or upgrading them, and then activating them, will be possible with
> zfs bootable environments (and will be a lot faster and easier, since 
> cloning will be
> almost instantaneous and will not require a preallocated slice).
> I''m not sure what will turn out to be a "gotcha" for
you, so let me just
> describe
> the basics of how zfs booting will work.  Some storage pools will be 
> designated
> as "root pools", which means that they contain at least one
dataset that
> contains
> a bootable root file system.  There will be some restrictions on root pools
> (the only allowed configuration is an n-way mirror of single disks or 
> slices,
> each of which must be accessible from the boot prom or BIOS), so best
> practice will be to keep data (such as database tables) in a pool separate
> from the root pool.  (The separation isn''t required but will
probably turn
> out to be best for ease of management.)
> Some datasets will be designated as "bootable", which means that
they
> contain
> a root file system.  A bootable environment (BE, in LiveUpgrade 
> terminology)
> can consist of several datasets, exactly one of which is
"bootable".
> For example, it will be desirable in many cases to put each zone root in a
> separate dataset.  Each of those zone root datasets will be subordinate 
> to a
> "bootable" dataset which contains the root of the BE.   Cloning a
BE means
> cloning each dataset in the BE.
> 
> We in the zfs-boot project owe the community more information about
> how the work is progressing.  I hope we can get more of that information
> out fairly soon.
> 
> Lori
> 

It would seem useful to separate the user''s data from the
system''s data
to prevent problems with losing mail, log file data, etc, when either
changing boot environments or pivoting root boot environments.

- Bart


-- 
Bart Smaalders			Solaris Kernel Performance
barts at cyber.eng.sun.com		http://blogs.sun.com/barts

On 11/11/06, Bart Smaalders <bart.smaalders at sun.com>
wrote:
> It would seem useful to separate the user''s data from the
system''s data
> to prevent problems with losing mail, log file data, etc, when either
> changing boot environments or pivoting root boot environments.
I''ll be more concerned about the confusion caused by losing the
changes when booting off different datasets but that problem exists
ZFS or otherwise.  I see a clear advantage in keeping more bootable
images than I can have "partitions" for especially when monkeying
around with the kernel codes.

-- 
Just me,
Wire ...

>On 11/11/06, Bart Smaalders <bart.smaalders at sun.com> wrote:
>> It would seem useful to separate the user''s data from the
system''s data
>> to prevent problems with losing mail, log file data, etc, when either
>> changing boot environments or pivoting root boot environments.
>
>I''ll be more concerned about the confusion caused by losing the
>changes when booting off different datasets but that problem exists
>ZFS or otherwise.  I see a clear advantage in keeping more bootable
>images than I can have "partitions" for especially when monkeying
>around with the kernel codes.
And I think this may also open the door for a "fallback" boot; if
booting
one root fs fails, we might be able to restart with another (but this
does seem to require modifying the pool in some way so it is not obvious
how this is done with errors really early in boot)

Casper

Casper.Dik at Sun.COM wrote:
>> On 11/11/06, Bart Smaalders <bart.smaalders at sun.com> wrote:
>>     
>>> It would seem useful to separate the user''s data from the
system''s data
>>> to prevent problems with losing mail, log file data, etc, when
either
>>> changing boot environments or pivoting root boot environments.
>>>       
>> I''ll be more concerned about the confusion caused by losing
the
>> changes when booting off different datasets but that problem exists
>> ZFS or otherwise.  I see a clear advantage in keeping more bootable
>> images than I can have "partitions" for especially when
monkeying
>> around with the kernel codes.
>>     
>
> And I think this may also open the door for a "fallback" boot; if
booting
> one root fs fails, we might be able to restart with another (but this
> does seem to require modifying the pool in some way so it is not obvious
> how this is done with errors really early in boot)
>   
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.

Lori
> Casper
>
>

>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.
	
Casper

On 14/11/06, Casper.Dik at sun.com <Casper.Dik at sun.com>
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.
Multiple grub entries would mitigate most risks (you can already define
multiple boot archives pointing at different zfs root filesystems, it''s
just
not automated).

I suppose it depends how ''catastrophic'' the failture is, but
if it''s
very low level,
booting another root probabyl won''t help, and if it''s too high
level, how will
you detect it (i.e. you''ve booted the kernel, but it is buggy).


--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

On 15/11/06, Casper.Dik at sun.com <Casper.Dik at sun.com>
wrote:
>
> >I suppose it depends how ''catastrophic'' the failture
is, but if it''s
> >very low level,
> >booting another root probabyl won''t help, and if it''s
too high level, how will
> >you detect it (i.e. you''ve booted the kernel, but it is
buggy).
>
> If it panics (but not too early) or fails to come up properly?
Detecting ''come up properly'' sounds hard
(as in ''turing test hard'') to me.

-- 
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

Dick Davies wrote:
> On 15/11/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote:
>>
>> >I suppose it depends how ''catastrophic'' the
failture is, but if it''s
>> >very low level,
>> >booting another root probabyl won''t help, and if
it''s too high level,
>> how will
>> >you detect it (i.e. you''ve booted the kernel, but it is
buggy).
>>
>> If it panics (but not too early) or fails to come up properly?
> 
> Detecting ''come up properly'' sounds hard
> (as in ''turing test hard'') to me.
It isn''t as hard as that.  In fact I don''t think it is
actually that
hard at all in the current Solaris architecture.

SMF helps a huge amount in this area because it has lots of failure 
detection and milestone/dependency concepts built in.

I think we first need to define what state "up" actually is.  Is it
the
kernel booted ?  Is it the root file system mounted ?  Is it we reached 
milestone all ?  Is it we reached milestone all with no services in 
maintenance ?  Is it no services in maintenance that weren''t on the
last
  boot ?

-- 
Darren J Moffat

>On 15/11/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote:
>>
>> >I suppose it depends how ''catastrophic'' the
failture is, but if it''s
>> >very low level,
>> >booting another root probabyl won''t help, and if
it''s too high level, how will
>> >you detect it (i.e. you''ve booted the kernel, but it is
buggy).
>>
>> If it panics (but not too early) or fails to come up properly?
>
>Detecting ''come up properly'' sounds hard
>(as in ''turing test hard'') to me.
Yep.  For one, I don''t think you can ever detect this for failures
before the root filesystem is mounted read-write.

Of course, since Sun is a system''s company, that bit can conceivably
be solved by changing the ILOM/ALOM to detect those.

But for those systems it is less of an issue because they can be
removely managed/powercycled/etc.


Casper

>I think we first need to define what state "up" actually is.  Is
it the
>kernel booted ?  Is it the root file system mounted ?  Is it we reached 
>milestone all ?  Is it we reached milestone all with no services in 
>maintenance ?  Is it no services in maintenance that weren''t on the
last
>  boot ?
I think that''s fairly simple: "up is the state when the milestone
we
are booting to has been actually reached".

What should SMF do when it finds that it cannot reach that milestone?

Harder is:

What is the system does not come up quickly enough?
What if the system hangs before SMF is even starts?
What if the system panics during boot or shortly after we
reach our desired milestone?

And then, of course, "define shortly and quickly".

Casper

On Wed, Nov 15, 2006 at 12:10:30PM +0100, Casper.Dik at Sun.COM
wrote:
> 
> >I think we first need to define what state "up" actually is. 
Is it the
> >kernel booted ?  Is it the root file system mounted ?  Is it we reached
> >milestone all ?  Is it we reached milestone all with no services in 
> >maintenance ?  Is it no services in maintenance that weren''t
on the last
> >  boot ?
> 
> I think that''s fairly simple: "up is the state when the
milestone we
> are booting to has been actually reached".
> 
> What should SMF do when it finds that it cannot reach that milestone?
Another question might be: how do I fix it when it''s broken?
> Harder is:
> 
> What is the system does not come up quickly enough?
> What if the system hangs before SMF is even starts?
> What if the system panics during boot or shortly after we
> reach our desired milestone?
> 
> And then, of course, "define shortly and quickly".
Such definitions to consider net and SAN booting.

Personally I think if a system is hosed then the best way to fail-safe
is to either panic or drop to single-user rather than trying to be
clever and booting some other kernel.

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061115/9082c3b0/attachment.bin>

On Tue, Nov 14, 2006 at 07:32:08PM +0100, Casper.Dik at Sun.COM
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.
Provide at least two GRUB menu entries: one for the latest BE, whatever
that is, and one for the last BE known to have booted to a multi-user
milestone.  Then have an SMF service update a ZFS property of the booted
BE to mark it as the last one to have booted.  This property should be a
date, so only the currently booted BE''s need be updated.

Nico
--

On Wed, Nov 15, 2006 at 11:00:01AM +0000, Darren J Moffat
wrote:
> I think we first need to define what state "up" actually is.  Is
it the
> kernel booted ?  Is it the root file system mounted ?  Is it we reached 
> milestone all ?  Is it we reached milestone all with no services in 
> maintenance ?  Is it no services in maintenance that weren''t on
the last
>  boot ?
It is that the default milestone has been reached, IMO (as opposed to a
milestone passed to the kernel as a boot argument).

On Wed, Nov 15, 2006 at 09:58:35PM +0000, Ceri Davies
wrote:
> On Wed, Nov 15, 2006 at 12:10:30PM +0100, Casper.Dik at Sun.COM wrote:
> > 
> > >I think we first need to define what state "up" actually
is.  Is it the
> > >kernel booted ?  Is it the root file system mounted ?  Is it we
reached
> > >milestone all ?  Is it we reached milestone all with no services
in
> > >maintenance ?  Is it no services in maintenance that
weren''t on the last
> > >  boot ?
> > 
> > I think that''s fairly simple: "up is the state when the
milestone we
> > are booting to has been actually reached".
> > 
> > What should SMF do when it finds that it cannot reach that milestone?
> 
> Another question might be: how do I fix it when it''s broken?
That''s for monitoring systems.  The issue here is how to best select a
BE at boot time.  IMO the last booted BE to have reached its default
milestone should be that BE.
> > Harder is:
> > 
> > What is the system does not come up quickly enough?
The user may note this and reboot the system.  BEs that once booted but
now don''t will still be selected at the GRUB menu as the last
known-to-boot BEs, so we may want the ZFS boot code to reset the
property of the BE''s used for making this selection.
> > What if the system hangs before SMF is even starts?
> > What if the system panics during boot or shortly after we
> > reach our desired milestone?
> > 
> > And then, of course, "define shortly and quickly".
> 
> Such definitions to consider net and SAN booting.
If you''re netbooting then you''re not doing a ZFS boot, so the
point is
moot (this thread is about how to best select a BE to boot at boot
time).  If you''re booting ZFS where the boot pool [or one or more or
all
of its mirror vdevs] is on a SAN then all the foregoing should apply.

Nico
--

On Wed, Nov 15, 2006 at 04:23:18PM -0600, Nicolas Williams
wrote:
> On Wed, Nov 15, 2006 at 09:58:35PM +0000, Ceri Davies wrote:
> > On Wed, Nov 15, 2006 at 12:10:30PM +0100, Casper.Dik at Sun.COM wrote:
> > > 
> > > >I think we first need to define what state "up"
actually is.  Is it the
> > > >kernel booted ?  Is it the root file system mounted ?  Is it
we reached
> > > >milestone all ?  Is it we reached milestone all with no
services in
> > > >maintenance ?  Is it no services in maintenance that
weren''t on the last
> > > >  boot ?
> > > 
> > > I think that''s fairly simple: "up is the state when
the milestone we
> > > are booting to has been actually reached".
> > > 
> > > What should SMF do when it finds that it cannot reach that
milestone?
> > 
> > Another question might be: how do I fix it when it''s broken?
> 
> That''s for monitoring systems.  The issue here is how to best
select a
> BE at boot time.  IMO the last booted BE to have reached its default
> milestone should be that BE.
What I''m trying to say (and this is the only part that you
didn''t quote
:)) is that there is no way I want the BE programatically selected.
> > > Harder is:
> > > 
> > > What is the system does not come up quickly enough?
> 
> The user may note this and reboot the system.  BEs that once booted but
> now don''t will still be selected at the GRUB menu as the last
> known-to-boot BEs, so we may want the ZFS boot code to reset the
> property of the BE''s used for making this selection.
Not my text, but wtf?  Booting the wrong BE because my NIS server is
down (or whatever) isn''t really acceptable (or likely to resolve
anything).  I think that''s what "not quickly enough" was
getting at.
> If you''re netbooting then you''re not doing a ZFS boot, so
the point is
> moot (this thread is about how to best select a BE to boot at boot
> time).
I believe I could have /usr or /var on NFS still.

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061115/4cdf5907/attachment.bin>

On Tue, Nov 14, 2006 at 07:32:08PM +0100, Casper.Dik at Sun.COM
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.

Ceri
-- 
That must be wonderful!  I don''t understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061115/f676de55/attachment.bin>

Ceri Davies wrote:
> On Tue, Nov 14, 2006 at 07:32:08PM +0100, Casper.Dik at Sun.COM 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

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, Casper.Dik at Sun.COM 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20061116/795d32ba/attachment.bin>

sorry, CCed to wrong list (should have been zfs-discuss).

On 15/11/06, Dick Davies <rasputnik@gmail.com>
wrote:
> On 14/11/06, Casper.Dik@sun.com <Casper.Dik@sun.com> 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,
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

>I suppose it depends how ''catastrophic'' the failture is,
but if it''s
>very low level,
>booting another root probabyl won''t help, and if it''s too
high level, how will
>you detect it (i.e. you''ve booted the kernel, but it is buggy).
If it panics (but not too early) or fails to come up properly?

Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

On 14/11/06, Casper.Dik@sun.com <Casper.Dik@sun.com>
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.
Multiple grub entries would mitigate most risks (you can already define
multiple boot archives pointing at different zfs root filesystems, it''s
just
not automated).

I suppose it depends how ''catastrophic'' the failture is, but
if it''s
very low level,
booting another root probabyl won''t help, and if it''s too high
level, how will
you detect it (i.e. you''ve booted the kernel, but it is buggy).


--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org