Re: [zfs-discuss] Thoughts on patching + zfs root
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
Re: [zfs-discuss] Thoughts on patching + zfs root
On 15/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] 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/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
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. 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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
On Wed, Nov 15, 2006 at 11:00:01AM +, 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). ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
On Wed, Nov 15, 2006 at 09:58:35PM +, Ceri Davies wrote: On Wed, Nov 15, 2006 at 12:10:30PM +0100, [EMAIL PROTECTED] 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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
On Wed, Nov 15, 2006 at 04:23:18PM -0600, Nicolas Williams wrote: On Wed, Nov 15, 2006 at 09:58:35PM +, Ceri Davies wrote: On Wed, Nov 15, 2006 at 12:10:30PM +0100, [EMAIL PROTECTED] 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 pgpx5pzictHCT.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
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. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgp37F69Un8zL.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
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
Re: [zfs-discuss] Thoughts on patching + zfs root
On 11/11/06, Bart Smaalders [EMAIL PROTECTED] 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 ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
On 11/11/06, Bart Smaalders [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
[EMAIL PROTECTED] wrote: On 11/11/06, Bart Smaalders [EMAIL PROTECTED] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on patching + zfs root
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
