From sacadmin Thu Feb  8 13:09:44 2007
Received: from cyber.eng.sun.com (cyber.SFBay.Sun.COM [129.146.228.109])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l18L9iM4011272;
	Thu, 8 Feb 2007 13:09:44 -0800 (PST)
Received: from cyber.eng.sun.com (localhost [127.0.0.1])
	by cyber.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l18L9HC8005929;
	Thu, 8 Feb 2007 13:09:17 -0800 (PST)
Received: (from ahrens@localhost)
	by cyber.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id l18L9H5l005909;
	Thu, 8 Feb 2007 13:09:17 -0800 (PST)
Date: Thu, 8 Feb 2007 13:09:17 -0800 (PST)
From: Matthew Ahrens <ahrens@cyber.eng.sun.com>
Message-Id: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
To: PSARC@sac.sfbay.sun.com
Cc: zfs-eng@sun.com
Subject: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Status: RO
Content-Length: 6570

Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets


Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2007 Sun Microsystems, Inc.
1. Introduction
    1.1. Project/Component Working Name:
	 ZFS bootable datasets
    1.2. Name of Document Author/Supplier:
	 Author:  Lori Alt
    1.3  Date of This Document:
	08 February, 2007
4. Technical Description
This case has patch/micro binding.  Interface stabilities are listed in
section 3.0.

2.0 Technical Description

This case defines new interfaces for the support of bootable
ZFS datasets.  Interfaces are provided by which a user or
application can designate the default bootable dataset of
a ZFS root pool and can override that default.

Summary:

A ZFS root pool is a storage pool that contains at least
one dataset that can be booted as the root file system.
Since a root pool can contain multiple bootable datasets, we
need a mechanism to designate the one that will be booted
by default when the system is started.  There is also a 
need for a mechanism by which the user can overrride the
default and identify the dataset to be booted.

Interfaces to be Defined:

2.1. A new pool property is defined:  "bootfs", which identifies
   the default bootable dataset for the root pool.  Only root
   pools may have this property defined (setting the property
   has the effect of designating the pool as a root pool).  If
   there is an attempt to set this property on a pool which
   does not meet the requirements of a root pool, the "zpool set bootfs"
   operation will fail.  A pool can be a root pool if it meets
   the following requirments:

     * The pool must be in a slice on a disk with an SMI label
       (i.e., a VTOC)..
     * The pool may be composed of a mirror device,
       but may not be composed of striped devices or a
       RAID-Z configuration.

   This new interface makes use of the pool properties feature,
   defined in PSARC/2006/577 (zpool property to disable delegation).

   To set this property, the following command would be executed:

       zpool set bootfs=<dataset-name> <rootpool>

   To clear this property, execute:

       zpool set bootfs="" <rootpool>

   To get the value of this property:

       zpool get bootfs <rootpool> ...

2.2. Two new zfs-related GRUB interfaces are defined.  These
   interfaces build on the new features added by 
   PSARC/2006/568 (direct boot (dboot) for x86).  The
   direct boot case added new "kernel$" and "module$"
   commands to GRUB.  These new commands are equivelant to the
   existing "kernel" and "module" commands, but with token
   substitution.

   a. A new GRUB command, "bootfs", is defined.  This command
      is of the following form:

      bootfs <name-of-dataset>

      If this command is specified, all further references to
      files in "kernel", "module", "kernel$", or "module$"
      commands will be resolved in the named dataset.  If no
      "bootfs" command is specified, and the root device
      contains a zfs pool, file references will be resolved
      in the default bootable dataset for the pool.

   b. A new GRUB token, "$ZFS-BOOTFS" is defined.  In the case
      where the root device contains a zfs pool, this token
      will be assigned a string value (the content of which
      is an interface private to zfs) which, when passed to
      the kernel using the -B option, will provide the necessary
      information for the kernel to identify the dataset
      to be booted.  The token substitution will take place
      when this token is specified on either a "kernel$" or
      "module$" GRUB command line.
  
   A GRUB menu entry for booting from a zfs dataset will look
   like this:

      title Solaris
      kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
      module$ /platform/i86pc/$ISADIR/boot_archive

   This entry will cause the system to be booted from the pool's
   default bootable dataset (as identified by the value of its
   "bootfs" property).  Or, if a user wished to specify an entry
   in the GRUB menu.lst file for booting from an alternate
   dataset in the pool, the user can add an entry like this:

      title Solaris-alternate-dataset
      bootfs myrootpool/bootenv-alt
      kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
      module$ /platform/i86pc/$ISADIR/boot_archive
 
3.0 Interface Table

 __________________________________________________________________________
|                          Interfaces Exported                             |
|___________________________|____________|_________________________________|
|Interface                  |Class       | Comments                        |
|___________________________|____________|_________________________________|
| GRUB 			    | Evolving   | Sun-contributed extensions      |
|     bootfs command        |		 | define bootable dataset         |
|     $ZFS-BOOTFS 	    |            | bootable dataset token          |
| bootfs pool property 	    | Committed  | default bootable dataset        |
|___________________________|____________|_________________________________|

4.0 Man page updates

The zpool(1m) man page will be modified to add this text
under "Properties":

	bootfs = <dataset> | ""

	    Defines the default bootable dataset for the pool.
	    The default bootable dataset is the dataset booted
	    by default when the system is booted from a device
	    in this pool.  Defining this property for a pool makes
	    it a root pool.  A root pool is one which is capable
	    of booting the system because it contains at least one
	    bootable dataset.  Root pools may be composed of mirrored	
	    devices, but may not be composed of concatenated devices
	    or a RAID-Z configuration.  If an attempt is made to set
	    this property on a pool which does not meet the requirements
	    of a root pool, the attempt will fail with an error.  The
	    bootfs property may be unset by setting the value of the
	    property to the empty string.
	    
5.0 Notes

This case is only intended to define the concept of a bootable
dataset.  It does not address the full set of issues regarding
booting from zfs.  Most significantly, it is not intended to address
installation issues.  When the interfaces defined by this case
are integrated, it will be possible to set up a system with a
zfs root filesystem using a set of manual actions, but not yet
with a standard install.

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack

From sacadmin Thu Feb  8 13:45:51 2007
Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l18LjpUX012123
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 13:45:51 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l18LjmhV029077;
	Thu, 8 Feb 2007 16:45:49 -0500 (EST)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l18LjmQG019705;
	Thu, 8 Feb 2007 16:45:48 -0500 (EST)
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
Cc: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
In-Reply-To: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
Content-Type: text/plain
Date: Thu, 08 Feb 2007 16:45:47 -0500
Message-Id: <1170971147.18202.16.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 1636

On Thu, 2007-02-08 at 13:09 -0800, Matthew Ahrens wrote:
> 2.2. Two new zfs-related GRUB interfaces are defined.  These
>    interfaces build on the new features added by 
>    PSARC/2006/568 (direct boot (dboot) for x86).  The
>    direct boot case added new "kernel$" and "module$"
>    commands to GRUB.  These new commands are equivelant to the
>    existing "kernel" and "module" commands, but with token
>    substitution.
> 
>    a. A new GRUB command, "bootfs", is defined.  This command
>       is of the following form:
...
>    b. A new GRUB token, "$ZFS-BOOTFS" is defined.  
...

Have you exposed this proposal with the upstream GRUB maintainers to at
least the same level that kernel$ and module$ were?  Did they have any
comments?

> 3.0 Interface Table
> 
>  __________________________________________________________________________
> |                          Interfaces Exported                             |
> |___________________________|____________|_________________________________|
> |Interface                  |Class       | Comments                        |
> |___________________________|____________|_________________________________|
> | GRUB 			    | Evolving   | Sun-contributed extensions      |
> |     bootfs command        |		 | define bootable dataset         |
> |     $ZFS-BOOTFS 	    |            | bootable dataset token          |
> | bootfs pool property 	    | Committed  | default bootable dataset        |
> |___________________________|____________|_________________________________|

"Evolving" is no longer a current taxonomy keyword.  Do you want
"Committed" or "Uncommitted".
	    


From sacadmin Thu Feb  8 14:05:52 2007
Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l18M5qb7012928
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 14:05:52 -0800 (PST)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l18M5qJw004178
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 14:05:52 -0800 (PST)
Received: from fe-amer-04.sun.com ([192.18.108.178])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l18M5pP2027797
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 15:05:51 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JD500F01ZJ4D800@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Thu, 08 Feb 2007 15:05:51 -0700 (MST)
Received: from [172.20.25.206] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JD6006L401RBG71@mail-amer.sun.com>; Thu,
 08 Feb 2007 15:05:51 -0700 (MST)
Date: Thu, 08 Feb 2007 15:05:52 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <1170971147.18202.16.camel@thunk>
Sender: Lori.Alt@Sun.COM
To: Bill Sommerfeld <sommerfeld@Sun.COM>
Cc: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM
Reply-to: Lori.Alt@Sun.COM
Message-id: <45CB9EC0.6040102@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <1170971147.18202.16.camel@thunk>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2189

Bill Sommerfeld wrote:
> On Thu, 2007-02-08 at 13:09 -0800, Matthew Ahrens wrote:
>   
>> 2.2. Two new zfs-related GRUB interfaces are defined.  These
>>    interfaces build on the new features added by 
>>    PSARC/2006/568 (direct boot (dboot) for x86).  The
>>    direct boot case added new "kernel$" and "module$"
>>    commands to GRUB.  These new commands are equivelant to the
>>    existing "kernel" and "module" commands, but with token
>>    substitution.
>>
>>    a. A new GRUB command, "bootfs", is defined.  This command
>>       is of the following form:
>>     
> ...
>   
>>    b. A new GRUB token, "$ZFS-BOOTFS" is defined.  
>>     
> ...
>
> Have you exposed this proposal with the upstream GRUB maintainers to at
> least the same level that kernel$ and module$ were?  Did they have any
> comments?
>
>   
I was not aware of the exposure that had been done re:  kernel$ and
module$.  I'll check with Jan Setje-Eilers to see what kind of contact
with the GRUB maintainers was done and should be done here.

>> 3.0 Interface Table
>>
>>  __________________________________________________________________________
>> |                          Interfaces Exported                             |
>> |___________________________|____________|_________________________________|
>> |Interface                  |Class       | Comments                        |
>> |___________________________|____________|_________________________________|
>> | GRUB 			    | Evolving   | Sun-contributed extensions      |
>> |     bootfs command        |		 | define bootable dataset         |
>> |     $ZFS-BOOTFS 	    |            | bootable dataset token          |
>> | bootfs pool property 	    | Committed  | default bootable dataset        |
>> |___________________________|____________|_________________________________|
>>     
>
> "Evolving" is no longer a current taxonomy keyword.  Do you want
> "Committed" or "Uncommitted".
> 	   
>   
I see that the final decision in 2006/568 (direct boot (dboot) for x86)
was to classify their $ISADIR token as "committed".   However, for
this case, given its specific applicability to zfs, I think the 
classification
should be "uncommitted". 


From sacadmin Thu Feb  8 16:18:05 2007
Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l190I5pr015206
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 16:18:05 -0800 (PST)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l190I3OV104869;
	Thu, 8 Feb 2007 16:18:04 -0800 (PST)
Message-ID: <45CBBD3E.8070901@sun.com>
Date: Thu, 08 Feb 2007 14:15:58 -1000
From: Joseph Kowalski <jek3@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
CC: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
In-Reply-To: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 659

Matthew Ahrens wrote:
> 5.0 Notes
>
> This case is only intended to define the concept of a bootable
> dataset.  It does not address the full set of issues regarding
> booting from zfs.  Most significantly, it is not intended to address
> installation issues.  When the interfaces defined by this case
> are integrated, it will be possible to set up a system with a
> zfs root filesystem using a set of manual actions, but not yet
> with a standard install.
>   
You say, "Most significantly ... installation".  I can live with that.

Are there other unresolved issues regarding booting from zfs?  If so, could
you briefly enumerate them.

- thanks,

- jek3


From sacadmin Thu Feb  8 16:22:35 2007
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l190MZKs015260
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 16:22:35 -0800 (PST)
Received: from zion.eng.sun.com (localhost [127.0.0.1])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l190MZPC007083;
	Thu, 8 Feb 2007 16:22:35 -0800 (PST)
Received: (from eschrock@localhost)
	by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id l190MZvT007082;
	Thu, 8 Feb 2007 16:22:35 -0800 (PST)
Date: Thu, 8 Feb 2007 16:22:35 -0800
From: Eric Schrock <eric.schrock@sun.com>
To: Joseph Kowalski <jek3@sun.com>
Cc: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Message-ID: <20070209002235.GL21381@eng.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <45CBBD3E.8070901@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45CBBD3E.8070901@sun.com>
User-Agent: Mutt/1.4.2.1i
Status: RO
Content-Length: 593

On Thu, Feb 08, 2007 at 02:15:58PM -1000, Joseph Kowalski wrote:
>
> You say, "Most significantly ... installation".  I can live with that.
> 
> Are there other unresolved issues regarding booting from zfs?  If so, could
> you briefly enumerate them.
>

One example:

6486493 zfs as a root file system and the sata framework don't interact properly

Because ZFS only opens by devices by devid or /dev path, there are some
bugs in devid implementations which prevent it from working properly
during boot.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

From sacadmin Thu Feb  8 19:59:50 2007
Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l193xowj018078
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 19:59:50 -0800 (PST)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l193xm9B141959;
	Thu, 8 Feb 2007 19:59:49 -0800 (PST)
Message-ID: <45CBF136.9090807@sun.com>
Date: Thu, 08 Feb 2007 17:57:42 -1000
From: Joseph Kowalski <jek3@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: Eric Schrock <eric.schrock@sun.com>
CC: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com>
In-Reply-To: <20070209002235.GL21381@eng.sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 1038

Eric Schrock wrote:
> On Thu, Feb 08, 2007 at 02:15:58PM -1000, Joseph Kowalski wrote:
>   
>> You say, "Most significantly ... installation".  I can live with that.
>>
>> Are there other unresolved issues regarding booting from zfs?  If so, could
>> you briefly enumerate them.
>>
>>     
>
> One example:
>
> 6486493 zfs as a root file system and the sata framework don't interact properly
>
> Because ZFS only opens by devices by devid or /dev path, there are some
> bugs in devid implementations which prevent it from working properly
> during boot.
>
> - Eric
>
> --
> Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
>   
What I'm probing for is "project completeness", which is why I ask for 
an enumeration.

Of course, I know you to be a straight forward fellow, so maybe I should 
just ask if this
project is sufficient to boot from zfs on the vast majority of hardware 
configurations provided
you do the magic to install such a configuration.

Heh, great idea!  I'm just asking....    8^)

- jek3


From sacadmin Thu Feb  8 21:33:55 2007
Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l195XtBH019017
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 21:33:55 -0800 (PST)
Received: from mcescher.eng.sun.com (localhost [127.0.0.1])
	by mcescher.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l195Xs4A662620;
	Thu, 8 Feb 2007 21:33:54 -0800 (PST)
Received: (from edp@localhost)
	by mcescher.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id l195Xs5a662619;
	Thu, 8 Feb 2007 21:33:54 -0800 (PST)
Date: Thu, 8 Feb 2007 21:33:54 -0800
From: Edward Pilatowicz <edward.pilatowicz@sun.com>
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
Cc: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Message-ID: <20070209053354.GD659639@eng.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
User-Agent: Mutt/1.4.2.1i
Status: RO
Content-Length: 7723

some comments/questions.

- with ufs most systems with more than one BE will have a "root (...)"
  grub menu entry.  does this proposal have any impact on this entry?
  (i'm guessing the answer is no, but i just wanted to be sure.)

- currently, the "root (...)" grub menu entry allows users to specify
  things like:
	root (<disk>, <partition> [, <vtoc_slice> ])
  did you consider changing this to support something like:
	root (<disk>, <partition> [, <vtoc_slice> [, <bootfs> ]])

- it seems strange to me to introduce a top level "bootfs" menu
  option to grub and then name the grub menu variable "ZFS-BOOTFS"
  (note that i'm assuming that if the user sets "bootfs" to "foo/bar"
  in the grub menu then "ZFS-BOOTFS" will get expanded to "foo/bar".)
  why don't these two entries have the same name?

ed

On Thu, Feb 08, 2007 at 01:09:17PM -0800, Matthew Ahrens wrote:
> Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets
>
>
> Template Version: @(#)sac_nextcase %I% %G% SMI
> This information is Copyright 2007 Sun Microsystems, Inc.
> 1. Introduction
>     1.1. Project/Component Working Name:
> 	 ZFS bootable datasets
>     1.2. Name of Document Author/Supplier:
> 	 Author:  Lori Alt
>     1.3  Date of This Document:
> 	08 February, 2007
> 4. Technical Description
> This case has patch/micro binding.  Interface stabilities are listed in
> section 3.0.
>
> 2.0 Technical Description
>
> This case defines new interfaces for the support of bootable
> ZFS datasets.  Interfaces are provided by which a user or
> application can designate the default bootable dataset of
> a ZFS root pool and can override that default.
>
> Summary:
>
> A ZFS root pool is a storage pool that contains at least
> one dataset that can be booted as the root file system.
> Since a root pool can contain multiple bootable datasets, we
> need a mechanism to designate the one that will be booted
> by default when the system is started.  There is also a
> need for a mechanism by which the user can overrride the
> default and identify the dataset to be booted.
>
> Interfaces to be Defined:
>
> 2.1. A new pool property is defined:  "bootfs", which identifies
>    the default bootable dataset for the root pool.  Only root
>    pools may have this property defined (setting the property
>    has the effect of designating the pool as a root pool).  If
>    there is an attempt to set this property on a pool which
>    does not meet the requirements of a root pool, the "zpool set bootfs"
>    operation will fail.  A pool can be a root pool if it meets
>    the following requirments:
>
>      * The pool must be in a slice on a disk with an SMI label
>        (i.e., a VTOC)..
>      * The pool may be composed of a mirror device,
>        but may not be composed of striped devices or a
>        RAID-Z configuration.
>
>    This new interface makes use of the pool properties feature,
>    defined in PSARC/2006/577 (zpool property to disable delegation).
>
>    To set this property, the following command would be executed:
>
>        zpool set bootfs=<dataset-name> <rootpool>
>
>    To clear this property, execute:
>
>        zpool set bootfs="" <rootpool>
>
>    To get the value of this property:
>
>        zpool get bootfs <rootpool> ...
>
> 2.2. Two new zfs-related GRUB interfaces are defined.  These
>    interfaces build on the new features added by
>    PSARC/2006/568 (direct boot (dboot) for x86).  The
>    direct boot case added new "kernel$" and "module$"
>    commands to GRUB.  These new commands are equivelant to the
>    existing "kernel" and "module" commands, but with token
>    substitution.
>
>    a. A new GRUB command, "bootfs", is defined.  This command
>       is of the following form:
>
>       bootfs <name-of-dataset>
>
>       If this command is specified, all further references to
>       files in "kernel", "module", "kernel$", or "module$"
>       commands will be resolved in the named dataset.  If no
>       "bootfs" command is specified, and the root device
>       contains a zfs pool, file references will be resolved
>       in the default bootable dataset for the pool.
>
>    b. A new GRUB token, "$ZFS-BOOTFS" is defined.  In the case
>       where the root device contains a zfs pool, this token
>       will be assigned a string value (the content of which
>       is an interface private to zfs) which, when passed to
>       the kernel using the -B option, will provide the necessary
>       information for the kernel to identify the dataset
>       to be booted.  The token substitution will take place
>       when this token is specified on either a "kernel$" or
>       "module$" GRUB command line.
>
>    A GRUB menu entry for booting from a zfs dataset will look
>    like this:
>
>       title Solaris
>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>       module$ /platform/i86pc/$ISADIR/boot_archive
>
>    This entry will cause the system to be booted from the pool's
>    default bootable dataset (as identified by the value of its
>    "bootfs" property).  Or, if a user wished to specify an entry
>    in the GRUB menu.lst file for booting from an alternate
>    dataset in the pool, the user can add an entry like this:
>
>       title Solaris-alternate-dataset
>       bootfs myrootpool/bootenv-alt
>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>       module$ /platform/i86pc/$ISADIR/boot_archive
>
> 3.0 Interface Table
>
>  __________________________________________________________________________
> |                          Interfaces Exported                             |
> |___________________________|____________|_________________________________|
> |Interface                  |Class       | Comments                        |
> |___________________________|____________|_________________________________|
> | GRUB 			    | Evolving   | Sun-contributed extensions      |
> |     bootfs command        |		 | define bootable dataset         |
> |     $ZFS-BOOTFS 	    |            | bootable dataset token          |
> | bootfs pool property 	    | Committed  | default bootable dataset        |
> |___________________________|____________|_________________________________|
>
> 4.0 Man page updates
>
> The zpool(1m) man page will be modified to add this text
> under "Properties":
>
> 	bootfs = <dataset> | ""
>
> 	    Defines the default bootable dataset for the pool.
> 	    The default bootable dataset is the dataset booted
> 	    by default when the system is booted from a device
> 	    in this pool.  Defining this property for a pool makes
> 	    it a root pool.  A root pool is one which is capable
> 	    of booting the system because it contains at least one
> 	    bootable dataset.  Root pools may be composed of mirrored
> 	    devices, but may not be composed of concatenated devices
> 	    or a RAID-Z configuration.  If an attempt is made to set
> 	    this property on a pool which does not meet the requirements
> 	    of a root pool, the attempt will fail with an error.  The
> 	    bootfs property may be unset by setting the value of the
> 	    property to the empty string.
>
> 5.0 Notes
>
> This case is only intended to define the concept of a bootable
> dataset.  It does not address the full set of issues regarding
> booting from zfs.  Most significantly, it is not intended to address
> installation issues.  When the interfaces defined by this case
> are integrated, it will be possible to set up a system with a
> zfs root filesystem using a set of manual actions, but not yet
> with a standard install.
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>    	6.4.1. Consolidation C-team Name:
> 		ON
>     6.5. ARC review type: FastTrack

From sacadmin Thu Feb  8 22:29:55 2007
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l196TtaM020001
	for <PSARC@sac.sfbay.sun.com>; Thu, 8 Feb 2007 22:29:55 -0800 (PST)
Received: from [192.9.61.125] (punchin-client-192-9-61-125 [192.9.61.125])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l196Tsa8015899;
	Thu, 8 Feb 2007 22:29:54 -0800 (PST)
Message-ID: <45CC151C.9020703@sun.com>
Date: Thu, 08 Feb 2007 22:30:52 -0800
From: Lin Ling <lin.ling@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: Edward Pilatowicz <edward.pilatowicz@sun.com>
CC: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com, nb-sparc@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com>
In-Reply-To: <20070209053354.GD659639@eng.sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 8490

Edward Pilatowicz wrote:
> some comments/questions.
>
> - with ufs most systems with more than one BE will have a "root (...)"
>   grub menu entry.  does this proposal have any impact on this entry?
>   (i'm guessing the answer is no, but i just wanted to be sure.)
>
>   

Right, the answer is no.

> - currently, the "root (...)" grub menu entry allows users to specify
>   things like:
> 	root (<disk>, <partition> [, <vtoc_slice> ])
>   did you consider changing this to support something like:
> 	root (<disk>, <partition> [, <vtoc_slice> [, <bootfs> ]])
>
>   

Yes, we considered this before.  We opted to add a new 'bootfs' command 
because:

1. extending an existing GRUB 'root' command involves unknown impact on 
other components.
    adding a new command is less dangerous.

2. we can use 'bootfs' for the default root device case (i.e. no "root 
(...)")

> - it seems strange to me to introduce a top level "bootfs" menu
>   option to grub and then name the grub menu variable "ZFS-BOOTFS"
>   (note that i'm assuming that if the user sets "bootfs" to "foo/bar"
>   in the grub menu then "ZFS-BOOTFS" will get expanded to "foo/bar".)
>   why don't these two entries have the same name?
>
>   

ZFS-BOOTFS is acturally expanded to an internal sring as 
"rootpool/rootfs-obj#"
for kernel zfs to identify which dataset to boot from.

> ed
>   

Thanks Ed for the questions/feedback.

Lin

> On Thu, Feb 08, 2007 at 01:09:17PM -0800, Matthew Ahrens wrote:
>   
>> Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets
>>
>>
>> Template Version: @(#)sac_nextcase %I% %G% SMI
>> This information is Copyright 2007 Sun Microsystems, Inc.
>> 1. Introduction
>>     1.1. Project/Component Working Name:
>> 	 ZFS bootable datasets
>>     1.2. Name of Document Author/Supplier:
>> 	 Author:  Lori Alt
>>     1.3  Date of This Document:
>> 	08 February, 2007
>> 4. Technical Description
>> This case has patch/micro binding.  Interface stabilities are listed in
>> section 3.0.
>>
>> 2.0 Technical Description
>>
>> This case defines new interfaces for the support of bootable
>> ZFS datasets.  Interfaces are provided by which a user or
>> application can designate the default bootable dataset of
>> a ZFS root pool and can override that default.
>>
>> Summary:
>>
>> A ZFS root pool is a storage pool that contains at least
>> one dataset that can be booted as the root file system.
>> Since a root pool can contain multiple bootable datasets, we
>> need a mechanism to designate the one that will be booted
>> by default when the system is started.  There is also a
>> need for a mechanism by which the user can overrride the
>> default and identify the dataset to be booted.
>>
>> Interfaces to be Defined:
>>
>> 2.1. A new pool property is defined:  "bootfs", which identifies
>>    the default bootable dataset for the root pool.  Only root
>>    pools may have this property defined (setting the property
>>    has the effect of designating the pool as a root pool).  If
>>    there is an attempt to set this property on a pool which
>>    does not meet the requirements of a root pool, the "zpool set bootfs"
>>    operation will fail.  A pool can be a root pool if it meets
>>    the following requirments:
>>
>>      * The pool must be in a slice on a disk with an SMI label
>>        (i.e., a VTOC)..
>>      * The pool may be composed of a mirror device,
>>        but may not be composed of striped devices or a
>>        RAID-Z configuration.
>>
>>    This new interface makes use of the pool properties feature,
>>    defined in PSARC/2006/577 (zpool property to disable delegation).
>>
>>    To set this property, the following command would be executed:
>>
>>        zpool set bootfs=<dataset-name> <rootpool>
>>
>>    To clear this property, execute:
>>
>>        zpool set bootfs="" <rootpool>
>>
>>    To get the value of this property:
>>
>>        zpool get bootfs <rootpool> ...
>>
>> 2.2. Two new zfs-related GRUB interfaces are defined.  These
>>    interfaces build on the new features added by
>>    PSARC/2006/568 (direct boot (dboot) for x86).  The
>>    direct boot case added new "kernel$" and "module$"
>>    commands to GRUB.  These new commands are equivelant to the
>>    existing "kernel" and "module" commands, but with token
>>    substitution.
>>
>>    a. A new GRUB command, "bootfs", is defined.  This command
>>       is of the following form:
>>
>>       bootfs <name-of-dataset>
>>
>>       If this command is specified, all further references to
>>       files in "kernel", "module", "kernel$", or "module$"
>>       commands will be resolved in the named dataset.  If no
>>       "bootfs" command is specified, and the root device
>>       contains a zfs pool, file references will be resolved
>>       in the default bootable dataset for the pool.
>>
>>    b. A new GRUB token, "$ZFS-BOOTFS" is defined.  In the case
>>       where the root device contains a zfs pool, this token
>>       will be assigned a string value (the content of which
>>       is an interface private to zfs) which, when passed to
>>       the kernel using the -B option, will provide the necessary
>>       information for the kernel to identify the dataset
>>       to be booted.  The token substitution will take place
>>       when this token is specified on either a "kernel$" or
>>       "module$" GRUB command line.
>>
>>    A GRUB menu entry for booting from a zfs dataset will look
>>    like this:
>>
>>       title Solaris
>>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>>       module$ /platform/i86pc/$ISADIR/boot_archive
>>
>>    This entry will cause the system to be booted from the pool's
>>    default bootable dataset (as identified by the value of its
>>    "bootfs" property).  Or, if a user wished to specify an entry
>>    in the GRUB menu.lst file for booting from an alternate
>>    dataset in the pool, the user can add an entry like this:
>>
>>       title Solaris-alternate-dataset
>>       bootfs myrootpool/bootenv-alt
>>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>>       module$ /platform/i86pc/$ISADIR/boot_archive
>>
>> 3.0 Interface Table
>>
>>  __________________________________________________________________________
>> |                          Interfaces Exported                             |
>> |___________________________|____________|_________________________________|
>> |Interface                  |Class       | Comments                        |
>> |___________________________|____________|_________________________________|
>> | GRUB 			    | Evolving   | Sun-contributed extensions      |
>> |     bootfs command        |		 | define bootable dataset         |
>> |     $ZFS-BOOTFS 	    |            | bootable dataset token          |
>> | bootfs pool property 	    | Committed  | default bootable dataset        |
>> |___________________________|____________|_________________________________|
>>
>> 4.0 Man page updates
>>
>> The zpool(1m) man page will be modified to add this text
>> under "Properties":
>>
>> 	bootfs = <dataset> | ""
>>
>> 	    Defines the default bootable dataset for the pool.
>> 	    The default bootable dataset is the dataset booted
>> 	    by default when the system is booted from a device
>> 	    in this pool.  Defining this property for a pool makes
>> 	    it a root pool.  A root pool is one which is capable
>> 	    of booting the system because it contains at least one
>> 	    bootable dataset.  Root pools may be composed of mirrored
>> 	    devices, but may not be composed of concatenated devices
>> 	    or a RAID-Z configuration.  If an attempt is made to set
>> 	    this property on a pool which does not meet the requirements
>> 	    of a root pool, the attempt will fail with an error.  The
>> 	    bootfs property may be unset by setting the value of the
>> 	    property to the empty string.
>>
>> 5.0 Notes
>>
>> This case is only intended to define the concept of a bootable
>> dataset.  It does not address the full set of issues regarding
>> booting from zfs.  Most significantly, it is not intended to address
>> installation issues.  When the interfaces defined by this case
>> are integrated, it will be possible to set up a system with a
>> zfs root filesystem using a set of manual actions, but not yet
>> with a standard install.
>>
>> 6. Resources and Schedule
>>     6.4. Steering Committee requested information
>>    	6.4.1. Consolidation C-team Name:
>> 		ON
>>     6.5. ARC review type: FastTrack
>>     


From sacadmin Fri Feb  9 10:20:32 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19IKWkS001426
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 10:20:32 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l19IKV1H023841
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 10:20:31 -0800 (PST)
Received: from fe-amer-01.sun.com ([192.18.108.175])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l19IKVnT014016
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 11:20:31 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JD700801K4O1G00@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Fri, 09 Feb 2007 11:20:31 -0700 (MST)
Received: from sun.com ([129.150.35.214])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JD700GQSKA6UVI0@mail-amer.sun.com>; Fri,
 09 Feb 2007 11:20:31 -0700 (MST)
Date: Fri, 09 Feb 2007 11:20:30 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45CBF136.9090807@sun.com>
Sender: Lori.Alt@Sun.COM
To: Joseph Kowalski <jek3@Sun.COM>
Cc: Eric Schrock <eric.schrock@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM
Message-id: <45CCBB6E.5000104@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com>
 <45CBF136.9090807@sun.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4)
 Gecko/20030624 Netscape/7.1
Status: RO
Content-Length: 3193



Joseph Kowalski wrote:

> Eric Schrock wrote:
>
>> On Thu, Feb 08, 2007 at 02:15:58PM -1000, Joseph Kowalski wrote:
>>  
>>
>>> You say, "Most significantly ... installation".  I can live with that.
>>>
>>> Are there other unresolved issues regarding booting from zfs?  If 
>>> so, could
>>> you briefly enumerate them.
>>>
>>>     
>>
>>
>> One example:
>>
>> 6486493 zfs as a root file system and the sata framework don't 
>> interact properly
>>
>> Because ZFS only opens by devices by devid or /dev path, there are some
>> bugs in devid implementations which prevent it from working properly
>> during boot.
>>
>> - Eric
>>
>> -- 
>> Eric Schrock, Solaris Kernel Development       
>> http://blogs.sun.com/eschrock
>>   
>
> What I'm probing for is "project completeness", which is why I ask for 
> an enumeration.
>
> Of course, I know you to be a straight forward fellow, so maybe I 
> should just ask if this
> project is sufficient to boot from zfs on the vast majority of 
> hardware configurations provided
> you do the magic to install such a configuration.

Well I'm not a fellow (and certainly not a Fellow), but I believe
that yes, this project is sufficient to boot the vast majority of x86
platforms.   It answers the question "What happens during a boot?"
It does not answer the question "How did the system get set up
this way in the first place?"  That's the install issue, which is at least
partly still being worked on. 

Here's what is still missing, besides install:

1.  The details of how OBP passes the dataset information to the
     kernel.  Actually, the sparc newboot project and the zfs boot
     projects have pretty much worked this out and we do have sparc
     systems booting from zfs.  But since sparc-newboot is still a
     not-quite-gelled project, I am holding off on specifying the exact
     interface yet in this case.  This project does however address part
     of the sparc interface.  The "bootfs" pool property will be used by
     both the GRUB and OBP booters to identify the default bootable
     dataset.

2.  Support for crash dumps into zfs pools.  There might not be any
     interfaces requiring ARC approval in order to complete this work.
     But in any case, nothing in this case will be affected by how dump
     works.

3.  The bug the Eric mentions.  I need to look into this and see if there's
     anything we need to do right now in the interface in order to enable
     or at least not prevent a fix to that bug in the future. 

The main reason for getting this interface integrated at this time
(as oppposed to waiting until the install support is implemented also)
is that we're getting lots of use and testing of zfs boot in the OpenSolaris
community and we need to update those bits so that those users
are working with something close to the final zfs boot design. 
Also, the Fishworks projects needs this support, but does not
need install.  None of that is a good enough reason to put back
an interface "before its time",  but these interfaces are sufficient
for the narrowly defined task of booting itself and have been
worked out in cooperation with the sparc newboot project and
the Xen and dboot project.

Lori


From sacadmin Fri Feb  9 10:38:44 2007
Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19IchJC001687
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 10:38:44 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19IccT6021122;
	Fri, 9 Feb 2007 13:38:38 -0500 (EST)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19Icc0B023828;
	Fri, 9 Feb 2007 13:38:38 -0500 (EST)
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Lori Alt <Lori.Alt@sun.com>
Cc: Joseph Kowalski <jek3@sun.com>, Eric Schrock <eric.schrock@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
In-Reply-To: <45CCBB6E.5000104@sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
	 <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com>
	 <45CBF136.9090807@sun.com>  <45CCBB6E.5000104@sun.com>
Content-Type: text/plain
Date: Fri, 09 Feb 2007 13:38:36 -0500
Message-Id: <1171046316.23444.11.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 1649

On Fri, 2007-02-09 at 11:20 -0700, Lori Alt wrote:
> Here's what is still missing, besides install:
> 
> 1.  The details of how OBP passes the dataset information to the
>      kernel.  Actually, the sparc newboot project and the zfs boot
>      projects have pretty much worked this out and we do have sparc
>      systems booting from zfs.  But since sparc-newboot is still a
>      not-quite-gelled project, I am holding off on specifying the exact
>      interface yet in this case.  This project does however address part
>      of the sparc interface.  The "bootfs" pool property will be used by
>      both the GRUB and OBP booters to identify the default bootable
>      dataset.
> 
> 2.  Support for crash dumps into zfs pools.  There might not be any
>      interfaces requiring ARC approval in order to complete this work.
>      But in any case, nothing in this case will be affected by how dump
>      works.
> 
> 3.  The bug the Eric mentions.  I need to look into this and see if there's
>      anything we need to do right now in the interface in order to enable
>      or at least not prevent a fix to that bug in the future. 

It sounds like the overall ZFS boot/root project is at a point where it
could benefit from an informal umbrella inception review where the
project and its interactions with the rest of the system can be
presented to a broader audience and there's a good chance that other
interactions/gaps/missing pieces might be exposed..

up to you, of course, but at the very least it could forestall  
"dumb questions" during later fast-track review of components as well as
last-minute surprises..

						- Bill




From sacadmin Fri Feb  9 11:28:03 2007
Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19JS3GH002539
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 11:28:03 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19JS2DV010970
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 11:28:02 -0800 (PST)
Received: from fe-amer-04.sun.com ([192.18.108.178])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l19JS2i4020948
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 12:28:02 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JD700L01NBJ3800@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Fri, 09 Feb 2007 12:28:02 -0700 (MST)
Received: from sun.com ([129.150.35.214])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JD7006JLNEJBGG1@mail-amer.sun.com>; Fri,
 09 Feb 2007 12:28:02 -0700 (MST)
Date: Fri, 09 Feb 2007 12:27:54 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <1171046316.23444.11.camel@thunk>
Sender: Lori.Alt@Sun.COM
To: Bill Sommerfeld <sommerfeld@Sun.COM>
Cc: Joseph Kowalski <jek3@Sun.COM>, Eric Schrock <eric.schrock@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM
Message-id: <45CCCB3A.6020205@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_taL2ad7MgXFKm+xGY6KKTw)"
X-Accept-Language: en-us, en
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com>
 <45CBF136.9090807@sun.com> <45CCBB6E.5000104@sun.com>
 <1171046316.23444.11.camel@thunk>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4)
 Gecko/20030624 Netscape/7.1
Status: RO
Content-Length: 4536

This is a multi-part message in MIME format.

--Boundary_(ID_taL2ad7MgXFKm+xGY6KKTw)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT



Bill Sommerfeld wrote:

>On Fri, 2007-02-09 at 11:20 -0700, Lori Alt wrote:
>  
>
>>Here's what is still missing, besides install:
>>
>>1.  The details of how OBP passes the dataset information to the
>>     kernel.  Actually, the sparc newboot project and the zfs boot
>>     projects have pretty much worked this out and we do have sparc
>>     systems booting from zfs.  But since sparc-newboot is still a
>>     not-quite-gelled project, I am holding off on specifying the exact
>>     interface yet in this case.  This project does however address part
>>     of the sparc interface.  The "bootfs" pool property will be used by
>>     both the GRUB and OBP booters to identify the default bootable
>>     dataset.
>>
>>2.  Support for crash dumps into zfs pools.  There might not be any
>>     interfaces requiring ARC approval in order to complete this work.
>>     But in any case, nothing in this case will be affected by how dump
>>     works.
>>
>>3.  The bug the Eric mentions.  I need to look into this and see if there's
>>     anything we need to do right now in the interface in order to enable
>>     or at least not prevent a fix to that bug in the future. 
>>    
>>
>
>It sounds like the overall ZFS boot/root project is at a point where it
>could benefit from an informal umbrella inception review where the
>project and its interactions with the rest of the system can be
>presented to a broader audience and there's a good chance that other
>interactions/gaps/missing pieces might be exposed..
>
>up to you, of course, but at the very least it could forestall  
>"dumb questions" during later fast-track review of components as well as
>last-minute surprises..
>
>  
>
Now that the interactions between zfs boot and sparc newboot,
Xen,  zulu, etc. have settled down, it's probably time to do this.
I'll work on getting materials submitted and a review scheduled.


Lori Alt

--Boundary_(ID_taL2ad7MgXFKm+xGY6KKTw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Bill Sommerfeld wrote:<br>
<blockquote type="cite" cite="mid1171046316.23444.11.camel@thunk">
  <pre wrap="">On Fri, 2007-02-09 at 11:20 -0700, Lori Alt wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Here's what is still missing, besides install:

1.  The details of how OBP passes the dataset information to the
     kernel.  Actually, the sparc newboot project and the zfs boot
     projects have pretty much worked this out and we do have sparc
     systems booting from zfs.  But since sparc-newboot is still a
     not-quite-gelled project, I am holding off on specifying the exact
     interface yet in this case.  This project does however address part
     of the sparc interface.  The "bootfs" pool property will be used by
     both the GRUB and OBP booters to identify the default bootable
     dataset.

2.  Support for crash dumps into zfs pools.  There might not be any
     interfaces requiring ARC approval in order to complete this work.
     But in any case, nothing in this case will be affected by how dump
     works.

3.  The bug the Eric mentions.  I need to look into this and see if there's
     anything we need to do right now in the interface in order to enable
     or at least not prevent a fix to that bug in the future. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It sounds like the overall ZFS boot/root project is at a point where it
could benefit from an informal umbrella inception review where the
project and its interactions with the rest of the system can be
presented to a broader audience and there's a good chance that other
interactions/gaps/missing pieces might be exposed..

up to you, of course, but at the very least it could forestall  
"dumb questions" during later fast-track review of components as well as
last-minute surprises..

  </pre>
</blockquote>
Now that the interactions between zfs boot and sparc newboot,<br>
Xen,&nbsp; zulu, etc. have settled down, it's probably time to do this.<br>
I'll work on getting materials submitted and a review scheduled.<br>
<br>
<br>
Lori Alt<br>
</body>
</html>

--Boundary_(ID_taL2ad7MgXFKm+xGY6KKTw)--

From sacadmin Fri Feb  9 12:30:20 2007
Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19KUKPn003283
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 12:30:20 -0800 (PST)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19KUJWx297399;
	Fri, 9 Feb 2007 12:30:19 -0800 (PST)
Message-ID: <45CCD95B.4000500@sun.com>
Date: Fri, 09 Feb 2007 10:28:11 -1000
From: Joseph Kowalski <jek3@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: Lori Alt <Lori.Alt@sun.com>
CC: Bill Sommerfeld <sommerfeld@sun.com>, Eric Schrock <eric.schrock@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com> <45CBF136.9090807@sun.com> <45CCBB6E.5000104@sun.com> <1171046316.23444.11.camel@thunk> <45CCCB3A.6020205@sun.com>
In-Reply-To: <45CCCB3A.6020205@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 482


> Now that the interactions between zfs boot and sparc newboot,
> Xen,  zulu, etc. have settled down, it's probably time to do this.
> I'll work on getting materials submitted and a review scheduled.
>
> Lori Alt
Not that its good fellow Lori's problem, but I think I'm having trouble
putting this together because of a lack of knowledge of the "newboot"
project.  (Does this go by another name? This isn't "direct boot", is it?)
Are there plans to have newboot incepted?

- jek3


From sacadmin Fri Feb  9 13:04:30 2007
Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19L4UG4003891
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 13:04:30 -0800 (PST)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19L4Trd026328
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 13:04:29 -0800 (PST)
Received: from fe-amer-01.sun.com ([192.18.108.175])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l19L4TU3028103
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 14:04:29 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JD700101RRFBR00@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Fri, 09 Feb 2007 14:04:29 -0700 (MST)
Received: from [172.20.25.206] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JD700GO9RVGUDC0@mail-amer.sun.com>; Fri,
 09 Feb 2007 14:04:29 -0700 (MST)
Date: Fri, 09 Feb 2007 14:04:30 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45CCD95B.4000500@sun.com>
Sender: Lori.Alt@Sun.COM
To: Joseph Kowalski <jek3@Sun.COM>
Cc: Bill Sommerfeld <sommerfeld@Sun.COM>, Eric Schrock <eric.schrock@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM
Reply-to: Lori.Alt@Sun.COM
Message-id: <45CCE1DE.5050104@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <45CBBD3E.8070901@sun.com> <20070209002235.GL21381@eng.sun.com>
 <45CBF136.9090807@sun.com> <45CCBB6E.5000104@sun.com>
 <1171046316.23444.11.camel@thunk> <45CCCB3A.6020205@sun.com>
 <45CCD95B.4000500@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1262

Joseph Kowalski wrote:
>
>> Now that the interactions between zfs boot and sparc newboot,
>> Xen,  zulu, etc. have settled down, it's probably time to do this.
>> I'll work on getting materials submitted and a review scheduled.
>>
>> Lori Alt
> Not that its good fellow Lori's problem, but I think I'm having trouble
> putting this together because of a lack of knowledge of the "newboot"
> project.  (Does this go by another name? This isn't "direct boot", is 
> it?)
> Are there plans to have newboot incepted?

The "sparc newboot" project I'm referring to is PSARC/2006/525
(new-boot sparc).  This is the project to implement ramdisk
miniroot support on sparc (largely to enable better support
for install time updates (ITUs)).  It makes sparc booting
similar to x86 booting in that both will have a boot archive,
which gets loaded into memory and accessed as a ramdisk.

Direct boot is part of Xen.  It makes the unix kernel module
compliant with the multiboot standard, which allows GRUB
to execute it directly, instead of first having to execute a
"multiboot" program which in turns starts the kernel.

We needed to adjust our design to be consistent with both
of these projects.  ZFS boot on both sparc and x86 assumes
the newboot-style of booting.

Lori

From sacadmin Fri Feb  9 14:58:44 2007
Received: from smack.Eng.Sun.COM (smack.SFBay.Sun.COM [129.146.226.114])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19MwhGa006191
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 14:58:43 -0800 (PST)
Received: from smack (localhost [127.0.0.1])
	by smack.Eng.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id l19MwNTG025787;
	Fri, 9 Feb 2007 14:58:23 -0800 (PST)
Message-Id: <200702092258.l19MwNTG025787@smack.Eng.Sun.COM>
X-Mailer: exmh version 2.6.3 04/04/2003 with version: MH 6.8.4 #31[UCI]
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
Cc: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 09 Feb 2007 14:58:23 -0800
From: Jan Setje-Eilers <setje@smack.Eng.Sun.COM>
Status: RO
Content-Length: 1053


 <responding to a forwarded mail, trying to get it onto the original 
  thread, apologies if this goes awry>

>    a. A new GRUB command, "bootfs", is defined.  This command
>       is of the following form: ...
>    b. A new GRUB token, "$ZFS-BOOTFS" is defined.   ...
> Have you exposed this proposal with the upstream GRUB maintainers to
> at least the same level that kernel$ and module$ were?  Did they
> have any comments?

 Asking them about stuff we do in legacy GRUB isn't particularly
useful. Basically noting we do there will go back, and 2.0 is
different enough (for instance it's got variable expansion) that we'll
likely want to re-think some of this stuff when/if we move to it.

 If you really want us to, we can post this to the GRUB list, but
without someone working on 2.0 it's kind or asking PSARC about some
orthogonal extension I'd like to make to SUNOS 4.11.

 This does bring up the point that we really need to be working on/
with GRUB 2.0 NOW, and due to other priorities and staffing we're
missing the boat. -- Sigh.

-jan



From sacadmin Fri Feb  9 15:30:20 2007
Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19NUKIZ006511
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 15:30:20 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19NUHSL014269;
	Fri, 9 Feb 2007 18:30:17 -0500 (EST)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19NUDKH003186;
	Fri, 9 Feb 2007 18:30:13 -0500 (EST)
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Jan Setje-Eilers <setje@smack.Eng.Sun.COM>
Cc: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
In-Reply-To: <200702092258.l19MwNTG025787@smack.Eng.Sun.COM>
References: <200702092258.l19MwNTG025787@smack.Eng.Sun.COM>
Content-Type: text/plain
Date: Fri, 09 Feb 2007 18:30:12 -0500
Message-Id: <1171063812.3117.3.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 992

On Fri, 2007-02-09 at 14:58 -0800, Jan Setje-Eilers wrote:
>  <responding to a forwarded mail, trying to get it onto the original 
>   thread, apologies if this goes awry>

it landed in the right place.  thanks!
>  Asking them about stuff we do in legacy GRUB isn't particularly
> useful. Basically noting we do there will go back, and 2.0 is
> different enough (for instance it's got variable expansion) that we'll
> likely want to re-think some of this stuff when/if we move to it.

This is the first i've heard of grub 2.0.  

>  If you really want us to, we can post this to the GRUB list, but
> without someone working on 2.0 it's kind or asking PSARC about some
> orthogonal extension I'd like to make to SUNOS 4.11.

Sure, but the fact that I asked make this clear...

>  This does bring up the point that we really need to be working on/
> with GRUB 2.0 NOW, and due to other priorities and staffing we're
> missing the boat. -- Sigh.

Indeed.  That's why I asked.  

						- Bill




From sacadmin Fri Feb  9 15:42:20 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19NgJUB006801
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 15:42:20 -0800 (PST)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l19NgJax016768
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 15:42:19 -0800 (PST)
Received: from fe-amer-10.sun.com ([192.18.108.184])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l19NgJVR028213
	for <PSARC@sac.sfbay.sun.com>; Fri, 9 Feb 2007 16:42:19 -0700 (MST)
Received: from sun.com ([129.147.156.114])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTP id <0JD700FT3Z6IZH0I@mail-amer.sun.com> for
 PSARC@sac.sfbay.sun.com; Fri, 09 Feb 2007 16:42:18 -0700 (MST)
Received: from [129.147.62.26] (Forwarded-For: 129.150.49.249)
 by bedge3-mail1.central.sun.com (mshttpd); Fri, 09 Feb 2007 16:42:18 -0700
Date: Fri, 09 Feb 2007 16:42:18 -0700
From: Joel Buckley <Joel.Buckley@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <1171063812.3117.3.camel@thunk>
To: Bill Sommerfeld <sommerfeld@Sun.COM>
Cc: Jan Setje-Eilers <setje@smack.Eng.Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM
Message-id: <f84a8ccf4e6d.45cca46a@sun.com>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr  3 2006)
Content-type: multipart/mixed; boundary="Boundary_(ID_LAPEzVpKgXF6TJPXH/xzGg)"
Content-language: en
X-Accept-Language: en
Priority: normal
References: <200702092258.l19MwNTG025787@smack.Eng.Sun.COM>
 <1171063812.3117.3.camel@thunk>
Status: RO
Content-Length: 2451

This is a multi-part message in MIME format.

--Boundary_(ID_LAPEzVpKgXF6TJPXH/xzGg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

GRUB Legacy:
http://www.gnu.org/software/grub/

GRUB 2, formerly PUPA:
http://www.gnu.org/software/grub/grub-2.en.html

Joel.Buckley@Sun.COM
JIST Development Lead
303-272-5556, x75556
"Luck is a Planned Event."

----- Original Message -----
From: Bill Sommerfeld <sommerfeld@Sun.COM>
Date: Friday, February 9, 2007 4:31 pm
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
To: Jan Setje-Eilers <setje@smack.Eng.Sun.COM>
Cc: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com, zfs-eng@Sun.COM

> On Fri, 2007-02-09 at 14:58 -0800, Jan Setje-Eilers wrote:
> >  <responding to a forwarded mail, trying to get it onto the 
> original 
> >   thread, apologies if this goes awry>
> 
> it landed in the right place.  thanks!
> >  Asking them about stuff we do in legacy GRUB isn't particularly
> > useful. Basically noting we do there will go back, and 2.0 is
> > different enough (for instance it's got variable expansion) that 
> we'll> likely want to re-think some of this stuff when/if we move 
> to it.
> 
> This is the first i've heard of grub 2.0.  
> 
> >  If you really want us to, we can post this to the GRUB list, but
> > without someone working on 2.0 it's kind or asking PSARC about some
> > orthogonal extension I'd like to make to SUNOS 4.11.
> 
> Sure, but the fact that I asked make this clear...
> 
> >  This does bring up the point that we really need to be working on/
> > with GRUB 2.0 NOW, and due to other priorities and staffing we're
> > missing the boat. -- Sigh.
> 
> Indeed.  That's why I asked.  
> 
>                                        	- Bill
> 
> 
> 
> 

--Boundary_(ID_LAPEzVpKgXF6TJPXH/xzGg)
Content-type: text/x-vcard; name=Joel.Buckley.vcf; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=Joel.Buckley.vcf
Content-description: Card for Joel Buckley <Joel.Buckley@Sun.COM>

begin:vcard
n:Buckley;Joel
fn:Joel W. Buckley
tel;fax:303-272-4194
tel;home:720-226-9370
tel;work:303-272-5556
url:sse.sfbay/interop/jist
org:Storage Group;System Test
adr:;;500 Eldorado Blvd., BRM05, Room3196;Broomfield;Colorado;80021-3400;USA
version:2.1
email;internet:Joel.Buckley@Sun.COM
title:JIST Development Lead
end:vcard

--Boundary_(ID_LAPEzVpKgXF6TJPXH/xzGg)--

From sacadmin Tue Feb 13 18:16:23 2007
Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1E2GNNJ015462
	for <PSARC@sac.sfbay.sun.com>; Tue, 13 Feb 2007 18:16:23 -0800 (PST)
Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1E2GHq1429011;
	Tue, 13 Feb 2007 18:16:17 -0800 (PST)
Message-ID: <45D27069.2060808@sun.com>
Date: Tue, 13 Feb 2007 16:14:01 -1000
From: Joseph Kowalski <jek3@sun.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
MIME-Version: 1.0
To: Lin Ling <lin.ling@sun.com>
CC: Edward Pilatowicz <edward.pilatowicz@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com, nb-sparc@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
In-Reply-To: <45CC151C.9020703@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 1141

Lin Ling wrote:
> Edward Pilatowicz wrote:
>> - currently, the "root (...)" grub menu entry allows users to specify
>>   things like:
>>     root (<disk>, <partition> [, <vtoc_slice> ])
>>   did you consider changing this to support something like:
>>     root (<disk>, <partition> [, <vtoc_slice> [, <bootfs> ]])
>
> Yes, we considered this before.  We opted to add a new 'bootfs' 
> command because:
>
> 1. extending an existing GRUB 'root' command involves unknown impact 
> on other components.
>    adding a new command is less dangerous.
>
> 2. we can use 'bootfs' for the default root device case (i.e. no "root 
> (...)")
At least #1, doesn't seem like the way to design this.  This isn't a 
"must be done by
tomorrow" project and these reasons don't seem architectually compelling.

I'll grant you its much a matter of style, but I think making zfs 
syntactically different
from all the other file system types (all the information to locate the 
root, isn't in the root
command) is counter intuitive and likely to bite us in the future.

I'd encourage the project team to reconsider (or if enough ARC members 
agree....).

- jek3


From sacadmin Wed Feb 14 10:02:43 2007
Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EI2he6003436
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:02:43 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6])
	by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l1EI2gCt000720
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:02:43 -0800 (PST)
Received: from d1-emea-09.sun.com ([192.18.2.119])
	by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1EI2aLx028574
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 18:02:37 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JDG00J01SSAMS00@d1-emea-09.sun.com>
 (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed,
 14 Feb 2007 18:02:36 +0000 (GMT)
Received: from [10.192.15.79] (192-18-45-134.Sun.COM [192.18.45.134])
 by d1-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JDG00APOSS8OB30@d1-emea-09.sun.com>; Wed,
 14 Feb 2007 18:02:35 +0000 (GMT)
Date: Wed, 14 Feb 2007 18:02:32 +0000
From: Darren J Moffat <Darren.Moffat@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45D27069.2060808@sun.com>
Sender: Darren.Moffat@Sun.COM
To: Joseph Kowalski <jek3@Sun.COM>
Cc: Lin Ling <lin.ling@Sun.COM>, Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Message-id: <45D34EB8.1070607@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com>
User-Agent: Thunderbird 1.5.0.8 (X11/20061127)
Status: RO
Content-Length: 1019

Joseph Kowalski wrote:
> I'll grant you its much a matter of style, but I think making zfs 
> syntactically different
> from all the other file system types (all the information to locate the 
> root, isn't in the root
> command) is counter intuitive and likely to bite us in the future.
> 
> I'd encourage the project team to reconsider (or if enough ARC members 
> agree....).

I agree too, I was very surprised to see bootfs introduced instead of 
using root().  This looks to me similar to the Linux use of initrd 
rather than using multiboot (yes I know the history isn't quite the same).

I really would like this to be done via the root property, I was 
expecting something like this for my single disk laptop that has a 
Solaris2 fdisk partition and a ZFS pool inside that:

root (hd0,2,a,zpool:mypool/root_snv_60)

IIRC Solaris already extended the root property for the Solaris VTOC 
'a,b,c...' entries so why not just extend that for ZFS as well and make 
the syntax clear that it is ZFS.
--
Darren J Moffat

From sacadmin Wed Feb 14 10:35:21 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EIZLG7005283
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:35:21 -0800 (PST)
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1EIZKtC024429
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:35:20 -0800 (PST)
Received: from fe-amer-05.sun.com ([192.18.108.179])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1EIZKQ0014213
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 11:35:20 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JDG00801U8XG200@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Wed, 14 Feb 2007 11:35:20 -0700 (MST)
Received: from [172.20.25.206] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JDG00680UAVCBU1@mail-amer.sun.com>; Wed,
 14 Feb 2007 11:35:20 -0700 (MST)
Date: Wed, 14 Feb 2007 11:35:21 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45D34EB8.1070607@Sun.COM>
Sender: Lori.Alt@Sun.COM
To: Darren J Moffat <Darren.Moffat@Sun.COM>
Cc: Joseph Kowalski <jek3@Sun.COM>, Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Reply-to: Lori.Alt@Sun.COM
Message-id: <45D35669.8080205@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 3475

Darren J Moffat wrote:
> Joseph Kowalski wrote:
>> I'll grant you its much a matter of style, but I think making zfs 
>> syntactically different
>> from all the other file system types (all the information to locate 
>> the root, isn't in the root
>> command) is counter intuitive and likely to bite us in the future.
>>
>> I'd encourage the project team to reconsider (or if enough ARC 
>> members agree....).
>
> I agree too, I was very surprised to see bootfs introduced instead of 
> using root().  This looks to me similar to the Linux use of initrd 
> rather than using multiboot (yes I know the history isn't quite the 
> same).

Since Joe's mail yesterday, Jan and Lin and I have been discussing this 
matter.

Some of our conclusions:

1.  The most usual way to specify the dataset to be booted as root
    will be NEITHER "bootfs" nor "root(...., <dataset>)".  The more
    common way should be to set the "bootfs" property of the pool
    to identify the default dataset.  Once that is done, then a totally
    generic zfs-boot entry in the menu.lst will be used to boot the
    default, whatever it is.  LiveUpgrade, for example, will implement
    "luactivate"  by setting the "bootfs" property on the root pool
    to the dataset being activated as the primary BE.  The "bootfs"
    command is intended solely to override the default behavior,
    should someone want to do that.

2.  (A comment from Lin, which I agree with:) The root command specifies
     a root device/slice. For zfs, it maps to a rootpool.   Once a slice (or
     a rootpool) is identified, using another command 'bootfs' to specify
     all possible root filesystems should be a natural flow.  Otherwise, we
     have to spell out the root slice everytime we specify another root
     filesystem in the same rootpool,  even when using BIOS root device
     as the default (when no need to use the root command).

     My comment now:  You could argue that it is just as natural, if not
     more natural, to separate the specification of the boot *device* from
     the boot *environment* ("BE", in liveupgrade terms).  In the ufs
     world, they are one and the same, but with ZFS, they are quite
     different and maybe it's best to make that clear instead of trying
     to co-mingle the concepts.

My preference is to leave the interface as we have originally specified
it, because (1) it should be rarely used anyway, and (2) boot environments
are not the same as boot devices and it's not unreasonable to specify
them separately, especially if you want to select a boot dataset without
having to explicitly specify the root device (which you may not even know
the GRUB name for.  It's just "whatever I set as the boot device").

(Related question:  Does the "root"  command have a "wild card" syntax,
that allows the root device to be specified as "*", or whatever?  If so,
adding the bootable dataset as an optional final field of the "root"
command might be workable, though I'm still not convinced it's
necessary or best.)

Lori
>
> I really would like this to be done via the root property, I was 
> expecting something like this for my single disk laptop that has a 
> Solaris2 fdisk partition and a ZFS pool inside that:
>
> root (hd0,2,a,zpool:mypool/root_snv_60)
>
> IIRC Solaris already extended the root property for the Solaris VTOC 
> 'a,b,c...' entries so why not just extend that for ZFS as well and 
> make the syntax clear that it is ZFS.
> -- 
> Darren J Moffat


From sacadmin Wed Feb 14 10:49:55 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EIntkF005883
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:49:55 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1EInsHx001305
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 10:49:54 -0800 (PST)
Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119])
	by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1EInmrF008956
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 18:49:48 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JDG00501UXHJM00@d1-emea-09.sun.com>
 (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed,
 14 Feb 2007 18:49:48 +0000 (GMT)
Received: from [10.192.15.79] (192-18-45-134.Sun.COM [192.18.45.134])
 by d1-emea-09.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JDG00AZ6UYXOB30@d1-emea-09.sun.com>; Wed,
 14 Feb 2007 18:49:48 +0000 (GMT)
Date: Wed, 14 Feb 2007 18:49:45 +0000
From: Darren J Moffat <Darren.Moffat@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45D35669.8080205@Sun.COM>
Sender: Darren.Moffat@Sun.COM
To: Lori.Alt@Sun.COM
Cc: Joseph Kowalski <jek3@Sun.COM>, Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Message-id: <45D359C9.1000000@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
 <45D35669.8080205@Sun.COM>
User-Agent: Thunderbird 1.5.0.8 (X11/20061127)
Status: RO
Content-Length: 269

Thanks for the update, I didn't notice that the bootfs property wouldn't 
be used most of the time.  In that case I think it is less of an issue.

Can you give an example menu.lst file for a single BE and for multiple 
BE's created by live upgrade.

--
Darren J Moffat

From sacadmin Wed Feb 14 11:49:34 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EJnYBK007467
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 11:49:34 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1EJnX3a001892
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 11:49:33 -0800 (PST)
Received: from fe-amer-05.sun.com ([192.18.108.179])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1EJnXl5023334
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 12:49:33 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JDG00001XCLWZ00@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Wed, 14 Feb 2007 12:49:33 -0700 (MST)
Received: from [172.20.25.206] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JDG0065PXQKC842@mail-amer.sun.com>; Wed,
 14 Feb 2007 12:49:33 -0700 (MST)
Date: Wed, 14 Feb 2007 12:49:34 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <45D359C9.1000000@Sun.COM>
Sender: Lori.Alt@Sun.COM
To: Darren J Moffat <Darren.Moffat@Sun.COM>
Cc: Joseph Kowalski <jek3@Sun.COM>, Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Reply-to: Lori.Alt@Sun.COM
Message-id: <45D367CE.2060605@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
 <45D35669.8080205@Sun.COM> <45D359C9.1000000@Sun.COM>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 1888

Darren J Moffat wrote:
> Thanks for the update, I didn't notice that the bootfs property 
> wouldn't be used most of the time.  In that case I think it is less of 
> an issue.
>
> Can you give an example menu.lst file for a single BE and for multiple 
> BE's created by live upgrade.
>
> -- 
> Darren J Moffat
LiveUpgrade has its own data structures for maintaining the
list of boot environments.  We don't want to duplicate the
information in the menu.lst file (or at least, we don't want
to require that the information be duplicated).

So, an entry like this:

      title Solaris
      kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
      module$ /platform/i86pc/$ISADIR/boot_archive

will typically be the only entry in the menu.lst file for booting from
zfs, regardless of how  many BEs there are.  When LU is used to
switch the "active" BE, the luactivate command will change the value
of the "bootfs" property for the pool.  The above menu.lst entry
will boot from whatever "bootfs" is set to. 

Now, we might want to have an option to LU to replicate the
list of BEs in the menu.lst file, if the user wants to be able to
select between BEs at the GRUB menu.  Or, the user could edit
the file directly and add separate entries for the various BEs
(each entry would have a "bootfs" command identifying
the dataset for that BE).  But typically, we would expect the
menu.lst file to have only the above entry and the user would
either use "luactive" or "zpool set bootfs=<dataset>" to
designate the default boot dataset.

The specifics of how LiveUpgrade will work with respect to
zfs boot datasets are not fully worked out.  I believe that
the mechanism we've come up with (the boot property,
plus the ability to override the boot property with "bootfs")
gives LiveUpgrade and eventually, Cayman, and other
install software, the flexibility  needed to manage BEs.

Lori

From sacadmin Wed Feb 14 11:58:16 2007
Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EJwGQC007856
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 11:58:16 -0800 (PST)
Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1EJw60m118147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Feb 2007 11:58:12 -0800 (PST)
Message-ID: <45D369CD.1050101@sun.com>
Date: Wed, 14 Feb 2007 14:58:05 -0500
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
User-Agent: Thunderbird 2.0pre (X11/20070214)
MIME-Version: 1.0
To: Lori.Alt@sun.com
CC: Darren J Moffat <Darren.Moffat@sun.com>, Joseph Kowalski <jek3@sun.com>,
        Lin Ling <lin.ling@sun.com>,
        Edward Pilatowicz <edward.pilatowicz@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com, nb-sparc@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com> <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM> <45D35669.8080205@Sun.COM> <45D359C9.1000000@Sun.COM> <45D367CE.2060605@Sun.COM>
In-Reply-To: <45D367CE.2060605@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 2243

Lori Alt wrote:

>  LiveUpgrade has its own data structures for maintaining the list of
>  boot environments.  We don't want to duplicate the information in the
>  menu.lst file (or at least, we don't want to require that the
>  information be duplicated).
>
>  So, an entry like this:
>
>  title Solaris kernel$ /platform/i86pc/kernel/$ISADIR/unix -B
>  $ZFS-BOOTFS module$ /platform/i86pc/$ISADIR/boot_archive
>
>  will typically be the only entry in the menu.lst file for booting
>  from zfs, regardless of how  many BEs there are.  When LU is used to
>  switch the "active" BE, the luactivate command will change the value
>  of the "bootfs" property for the pool.  The above menu.lst entry will
>  boot from whatever "bootfs" is set to. Now, we might want to have an
>  option to LU to replicate the list of BEs in the menu.lst file, if
>  the user wants to be able to select between BEs at the GRUB menu.
>  Or, the user could edit


I think this is an important feature - the ability to choose which BE to 
boot
into from the grub menu.  It's certainly easier than booting, running 
'luactivate'
(or some zfs command) and rebooting again.   Currently, when you LU, you 
are
presented with both BEs on the grub menu, it would be a shame to lose that
functionality.


>  the file directly and add separate entries for the various BEs (each
>  entry would have a "bootfs" command identifying the dataset for that
>  BE).  But typically, we would expect the menu.lst file to have only
>  the above entry and the user would either use "luactive" or "zpool
>  set bootfs=<dataset>" to designate the default boot dataset.


But then you are forcing the user to take extra time and steps
in order to get back to the old BE.  Keeping 2 entries in grub
would seem to be much easier on the end user.


>
>  The specifics of how LiveUpgrade will work with respect to zfs boot
>  datasets are not fully worked out.  I believe that the mechanism
>  we've come up with (the boot property, plus the ability to override
>  the boot property with "bootfs") gives LiveUpgrade and eventually,
>  Cayman, and other install software, the flexibility  needed to manage
>  BEs.
>


I think it is a bit of a regression from the current LU operation.

-Wyllys



From sacadmin Wed Feb 14 12:24:02 2007
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EKO1Yr008057
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 12:24:01 -0800 (PST)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1EKNPSb010747;
	Wed, 14 Feb 2007 14:23:25 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.6+Sun/8.13.6/Submit) id l1EKNPgk010746;
	Wed, 14 Feb 2007 14:23:25 -0600 (CST)
Date: Wed, 14 Feb 2007 14:23:25 -0600
From: Nicolas Williams <Nicolas.Williams@Sun.COM>
To: Lori Alt <Lori.Alt@Sun.COM>
Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, Joseph Kowalski <jek3@Sun.COM>,
        Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Message-ID: <20070214202324.GD9435@binky.central.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com> <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM> <45D35669.8080205@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45D35669.8080205@Sun.COM>
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 900

On Wed, Feb 14, 2007 at 11:35:21AM -0700, Lori Alt wrote:
> My preference is to leave the interface as we have originally specified
> it, because (1) it should be rarely used anyway, and (2) boot environments
> are not the same as boot devices and it's not unreasonable to specify
> them separately, especially if you want to select a boot dataset without
> having to explicitly specify the root device (which you may not even know
> the GRUB name for.  It's just "whatever I set as the boot device").
> 
> (Related question:  Does the "root"  command have a "wild card" syntax,
> that allows the root device to be specified as "*", or whatever?  If so,
> adding the bootable dataset as an optional final field of the "root"
> command might be workable, though I'm still not convinced it's
> necessary or best.)

Oooh, "taste" all storage, if you find a suitable ZFS pool, use it as
the root device.

From sacadmin Wed Feb 14 13:43:04 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1ELh4iR009703
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 13:43:04 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l1ELh3mo024039
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 13:43:04 -0800 (PST)
Received: from fe-amer-04.sun.com ([192.18.108.178])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1ELh35e020189
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 14:43:03 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JDH00J012Z18N00@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Wed, 14 Feb 2007 14:43:03 -0700 (MST)
Received: from sun.com ([129.150.32.237])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3
 2006)) with ESMTPSA id <0JDH006YW2ZKBF52@mail-amer.sun.com>; Wed,
 14 Feb 2007 14:43:03 -0700 (MST)
Date: Wed, 14 Feb 2007 14:42:57 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <20070214202324.GD9435@binky.central.sun.com>
Sender: Lori.Alt@Sun.COM
To: Nicolas Williams <Nicolas.Williams@Sun.COM>
Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, Joseph Kowalski <jek3@Sun.COM>,
        Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Message-id: <45D38261.50202@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_6vnHXUehby6NuzHKhyO3Uw)"
X-Accept-Language: en-us, en
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
 <45D35669.8080205@Sun.COM> <20070214202324.GD9435@binky.central.sun.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4)
 Gecko/20030624 Netscape/7.1
Status: RO
Content-Length: 3253

This is a multi-part message in MIME format.

--Boundary_(ID_6vnHXUehby6NuzHKhyO3Uw)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT



Nicolas Williams wrote:

>On Wed, Feb 14, 2007 at 11:35:21AM -0700, Lori Alt wrote:
>  
>
>>My preference is to leave the interface as we have originally specified
>>it, because (1) it should be rarely used anyway, and (2) boot environments
>>are not the same as boot devices and it's not unreasonable to specify
>>them separately, especially if you want to select a boot dataset without
>>having to explicitly specify the root device (which you may not even know
>>the GRUB name for.  It's just "whatever I set as the boot device").
>>
>>(Related question:  Does the "root"  command have a "wild card" syntax,
>>that allows the root device to be specified as "*", or whatever?  If so,
>>adding the bootable dataset as an optional final field of the "root"
>>command might be workable, though I'm still not convinced it's
>>necessary or best.)
>>    
>>
>
>Oooh, "taste" all storage, if you find a suitable ZFS pool, use it as
>the root device.
>

That's not what I meant (maybe you know that and you're
joking.  Sorry if that's true and I'm taking you seriously).  But
just to be clear, I mean that the wildcard character would be
replaced by "whatever boot device would be the default in
the absence of a 'root' command"

Lori

--Boundary_(ID_6vnHXUehby6NuzHKhyO3Uw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Nicolas Williams wrote:<br>
<blockquote type="cite"
 cite="mid20070214202324.GD9435@binky.central.sun.com">
  <pre wrap="">On Wed, Feb 14, 2007 at 11:35:21AM -0700, Lori Alt wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">My preference is to leave the interface as we have originally specified
it, because (1) it should be rarely used anyway, and (2) boot environments
are not the same as boot devices and it's not unreasonable to specify
them separately, especially if you want to select a boot dataset without
having to explicitly specify the root device (which you may not even know
the GRUB name for.  It's just "whatever I set as the boot device").

(Related question:  Does the "root"  command have a "wild card" syntax,
that allows the root device to be specified as "*", or whatever?  If so,
adding the bootable dataset as an optional final field of the "root"
command might be workable, though I'm still not convinced it's
necessary or best.)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Oooh, "taste" all storage, if you find a suitable ZFS pool, use it as
the root device.</pre>
</blockquote>
<br>
That's not what I meant (maybe you know that and you're<br>
joking.&nbsp; Sorry if that's true and I'm taking you seriously).&nbsp; But<br>
just to be clear, I mean that the wildcard character would be<br>
replaced by "whatever boot device would be the default in<br>
the absence of a 'root' command"<br>
<br>
Lori<br>
</body>
</html>

--Boundary_(ID_6vnHXUehby6NuzHKhyO3Uw)--

From sacadmin Wed Feb 14 13:53:09 2007
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1ELr9oi009976
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Feb 2007 13:53:09 -0800 (PST)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1ELqXki010842;
	Wed, 14 Feb 2007 15:52:33 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.6+Sun/8.13.6/Submit) id l1ELqX18010841;
	Wed, 14 Feb 2007 15:52:33 -0600 (CST)
Date: Wed, 14 Feb 2007 15:52:33 -0600
From: Nicolas Williams <Nicolas.Williams@Sun.COM>
To: Lori Alt <Lori.Alt@Sun.COM>
Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, Joseph Kowalski <jek3@Sun.COM>,
        Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Message-ID: <20070214215229.GL9435@binky.central.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com> <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM> <45D35669.8080205@Sun.COM> <20070214202324.GD9435@binky.central.sun.com> <45D38261.50202@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45D38261.50202@sun.com>
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 672

On Wed, Feb 14, 2007 at 02:42:57PM -0700, Lori Alt wrote:
> Nicolas Williams wrote:
> >Oooh, "taste" all storage, if you find a suitable ZFS pool, use it as
> >the root device.
> >
> 
> That's not what I meant (maybe you know that and you're
> joking.  Sorry if that's true and I'm taking you seriously).  But

I knew what you meant and I wasn't quite joking :)  Would it be useful
to search for a bootable dataset by a given name on any visible device,
as opposed to only the one whence GRUB came?

> just to be clear, I mean that the wildcard character would be
> replaced by "whatever boot device would be the default in
> the absence of a 'root' command"

Understood.

From sacadmin Fri Mar  2 13:22:28 2007
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l22LMSqv002317
	for <PSARC@sac.sfbay.sun.com>; Fri, 2 Mar 2007 13:22:28 -0800 (PST)
Received: from [129.146.228.109] (cyber [129.146.228.109])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l22LMQDJ007102;
	Fri, 2 Mar 2007 13:22:27 -0800 (PST)
Message-ID: <45E8956A.5010401@sun.com>
Date: Fri, 02 Mar 2007 13:21:46 -0800
From: Matthew Ahrens <Matthew.Ahrens@sun.com>
User-Agent: Thunderbird 1.5.0.8 (X11/20061204)
MIME-Version: 1.0
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
CC: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
In-Reply-To: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 156

Matthew Ahrens wrote:
> Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets

Case timed out with all issues resolved; closing as approved.

--matt

From sacadmin Fri Mar  2 13:47:14 2007
Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l22LlDIt002726
	for <PSARC@sac.sfbay.sun.com>; Fri, 2 Mar 2007 13:47:14 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l22LlBMj025709;
	Fri, 2 Mar 2007 16:47:11 -0500 (EST)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l22LlAH4018017;
	Fri, 2 Mar 2007 16:47:10 -0500 (EST)
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Matthew Ahrens <Matthew.Ahrens@sun.com>
Cc: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
In-Reply-To: <45E8956A.5010401@sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
	 <45E8956A.5010401@sun.com>
Content-Type: text/plain
Date: Fri, 02 Mar 2007 16:47:09 -0500
Message-Id: <1172872029.17420.25.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 395

On Fri, 2007-03-02 at 13:21 -0800, Matthew Ahrens wrote:
> Matthew Ahrens wrote:
> > Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets
> 
> Case timed out with all issues resolved; closing as approved.

I asked for more time during wednesday's meeting, and have been too
swamped since then to follow up. 

in general, the case sponsor should be on the call to catch these
requests.



From sacadmin Fri Mar  2 13:53:35 2007
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l22LrZIv002835
	for <PSARC@sac.sfbay.sun.com>; Fri, 2 Mar 2007 13:53:35 -0800 (PST)
Received: from [129.146.228.109] (cyber [129.146.228.109])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l22LrXBd008397;
	Fri, 2 Mar 2007 13:53:34 -0800 (PST)
Message-ID: <45E89CB6.10603@sun.com>
Date: Fri, 02 Mar 2007 13:52:54 -0800
From: Matthew Ahrens <Matthew.Ahrens@sun.com>
User-Agent: Thunderbird 1.5.0.8 (X11/20061204)
MIME-Version: 1.0
To: Bill Sommerfeld <sommerfeld@sun.com>
CC: Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>	 <45E8956A.5010401@sun.com> <1172872029.17420.25.camel@thunk>
In-Reply-To: <1172872029.17420.25.camel@thunk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 563

Bill Sommerfeld wrote:
> On Fri, 2007-03-02 at 13:21 -0800, Matthew Ahrens wrote:
>> Matthew Ahrens wrote:
>>> Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets
>> Case timed out with all issues resolved; closing as approved.
> 
> I asked for more time during wednesday's meeting, and have been too
> swamped since then to follow up. 
> 
> in general, the case sponsor should be on the call to catch these
> requests.

Sorry, that's me.  I checked the meeting notes but didn't see anything 
about it.  I'll reset the timeout to next wednesday.

--matt

From sacadmin Fri Mar  2 19:15:17 2007
Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l233FH2S010862
	for <PSARC@sac.sfbay.sun.com>; Fri, 2 Mar 2007 19:15:17 -0800 (PST)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l233ExU3008243;
	Fri, 2 Mar 2007 22:14:59 -0500 (EST)
Received: from [IPv6:::1] (localhost [IPv6:::1])
	by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l233Exwv020423;
	Fri, 2 Mar 2007 22:14:59 -0500 (EST)
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Lori.Alt@sun.com
Cc: Darren J Moffat <Darren.Moffat@sun.com>, Joseph Kowalski <jek3@sun.com>,
        Lin Ling <lin.ling@sun.com>,
        Edward Pilatowicz <edward.pilatowicz@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com, nb-sparc@sun.com
In-Reply-To: <45D367CE.2060605@Sun.COM>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
	 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
	 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
	 <45D35669.8080205@Sun.COM> <45D359C9.1000000@Sun.COM>
	 <45D367CE.2060605@Sun.COM>
Content-Type: text/plain
Date: Fri, 02 Mar 2007 22:14:58 -0500
Message-Id: <1172891698.17420.79.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1.1 
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 952

My apologies for not raising this issue sooner.  A worm infestation on
Tuesday got in the way....

On Wed, 2007-02-14 at 12:49 -0700, Lori Alt wrote:
> So, an entry like this:
> 
>       title Solaris
>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>       module$ /platform/i86pc/$ISADIR/boot_archive
> 
> will typically be the only entry in the menu.lst file for booting from
> zfs, regardless of how  many BEs there are.  When LU is used to
> switch the "active" BE, the luactivate command will change the value
> of the "bootfs" property for the pool.  The above menu.lst entry
> will boot from whatever "bootfs" is set to. 

In the event that the new "active" BE turned out to be a brick when
actually booted, how do you find an alternate BE to boot?  With the
current LU-GRUB interaction it's straightforward because each BE has a
menu.lst entry (two, actually) and you just use the GRUB menu to select
another.

					- Bill



From sacadmin Sat Mar  3 12:25:39 2007
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l23KPdj4013318
	for <PSARC@sac.sfbay.sun.com>; Sat, 3 Mar 2007 12:25:39 -0800 (PST)
Received: from binky.central.sun.com (localhost [127.0.0.1])
	by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l23KP69m014383;
	Sat, 3 Mar 2007 14:25:06 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l23KP6u6014382;
	Sat, 3 Mar 2007 14:25:06 -0600 (CST)
Date: Sat, 3 Mar 2007 14:25:06 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Bill Sommerfeld <sommerfeld@sun.com>
Cc: Lori.Alt@sun.com, Darren J Moffat <Darren.Moffat@sun.com>,
        Joseph Kowalski <jek3@sun.com>, Lin Ling <lin.ling@sun.com>,
        Edward Pilatowicz <edward.pilatowicz@sun.com>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@sun.com, nb-sparc@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
Message-ID: <20070303202505.GG18346@binky.central.sun.com>
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com> <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com> <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM> <45D35669.8080205@Sun.COM> <45D359C9.1000000@Sun.COM> <45D367CE.2060605@Sun.COM> <1172891698.17420.79.camel@thunk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1172891698.17420.79.camel@thunk>
User-Agent: Mutt/1.5.7i
Status: RO
Content-Length: 1407

On Fri, Mar 02, 2007 at 10:14:58PM -0500, Bill Sommerfeld wrote:
> My apologies for not raising this issue sooner.  A worm infestation on
> Tuesday got in the way....
> 
> On Wed, 2007-02-14 at 12:49 -0700, Lori Alt wrote:
> > So, an entry like this:
> > 
> >       title Solaris
> >       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
> >       module$ /platform/i86pc/$ISADIR/boot_archive
> > 
> > will typically be the only entry in the menu.lst file for booting from
> > zfs, regardless of how  many BEs there are.  When LU is used to
> > switch the "active" BE, the luactivate command will change the value
> > of the "bootfs" property for the pool.  The above menu.lst entry
> > will boot from whatever "bootfs" is set to. 
> 
> In the event that the new "active" BE turned out to be a brick when
> actually booted, how do you find an alternate BE to boot?  With the
> current LU-GRUB interaction it's straightforward because each BE has a
> menu.lst entry (two, actually) and you just use the GRUB menu to select
> another.

I thought that one would be able to edit the grub menu entry ('e' at the
menu), backspace over "$ZFS-BOOTFS" and type in the name of the desired
dataset, but then I noticed that the $ZFS-BOOTFS token's content is
private.  Hmmmm.  It'd be useful if it wasn't private.  It'd be even
more useful if grub could list all the available bootable datasets :)

Nico
-- 

From sacadmin Mon Mar  5 08:11:32 2007
Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25GBW3Z009296
	for <PSARC@sac.sfbay.sun.com>; Mon, 5 Mar 2007 08:11:32 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31])
	by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l25GBWIq022356
	for <PSARC@sac.sfbay.sun.com>; Mon, 5 Mar 2007 08:11:32 -0800 (PST)
Received: from fe-amer-06.sun.com ([192.18.108.180])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l25GBVYn029993
	for <PSARC@sac.sfbay.sun.com>; Mon, 5 Mar 2007 16:11:32 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JEF00B01U1G7J00@mail-amer.sun.com> (original mail from Lori.Alt@Sun.COM)
 for PSARC@sac.sfbay.sun.com; Mon, 05 Mar 2007 09:11:31 -0700 (MST)
Received: from [172.20.25.206] by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JEF0063MUB79MG3@mail-amer.sun.com>; Mon,
 05 Mar 2007 09:11:31 -0700 (MST)
Date: Mon, 05 Mar 2007 09:11:35 -0700
From: Lori Alt <Lori.Alt@Sun.COM>
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
In-reply-to: <1172891698.17420.79.camel@thunk>
Sender: Lori.Alt@Sun.COM
To: Bill Sommerfeld <sommerfeld@Sun.COM>
Cc: Darren J Moffat <Darren.Moffat@Sun.COM>, Joseph Kowalski <jek3@Sun.COM>,
        Lin Ling <lin.ling@Sun.COM>,
        Edward Pilatowicz <edward.pilatowicz@Sun.COM>,
        Matthew Ahrens <ahrens@cyber.eng.sun.com>, PSARC@sac.sfbay.sun.com,
        zfs-eng@Sun.COM, nb-sparc@Sun.COM
Reply-to: Lori.Alt@Sun.COM
Message-id: <45EC4137.4030605@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
 <20070209053354.GD659639@eng.sun.com> <45CC151C.9020703@sun.com>
 <45D27069.2060808@sun.com> <45D34EB8.1070607@Sun.COM>
 <45D35669.8080205@Sun.COM> <45D359C9.1000000@Sun.COM>
 <45D367CE.2060605@Sun.COM> <1172891698.17420.79.camel@thunk>
User-Agent: Thunderbird 1.5.0.5 (X11/20060925)
Status: RO
Content-Length: 2410

Bill Sommerfeld wrote:
> My apologies for not raising this issue sooner.  A worm infestation on
> Tuesday got in the way....
>
> On Wed, 2007-02-14 at 12:49 -0700, Lori Alt wrote:
>   
>> So, an entry like this:
>>
>>       title Solaris
>>       kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
>>       module$ /platform/i86pc/$ISADIR/boot_archive
>>
>> will typically be the only entry in the menu.lst file for booting from
>> zfs, regardless of how  many BEs there are.  When LU is used to
>> switch the "active" BE, the luactivate command will change the value
>> of the "bootfs" property for the pool.  The above menu.lst entry
>> will boot from whatever "bootfs" is set to. 
>>     
>
> In the event that the new "active" BE turned out to be a brick when
> actually booted, how do you find an alternate BE to boot?  With the
> current LU-GRUB interaction it's straightforward because each BE has a
> menu.lst entry (two, actually) and you just use the GRUB menu to select
> another.
>
>   
The infrastructure proposed by this case allows LU to implement the
above capability.  LU can create GRUB menu entries for each known
BE.  Each one would have a "rootfs <dataset-name>" line that specifies
the ataset that contains the root file system for that BE. 

It has become clear from feedback from various sources (this
case mail thread, my talk at the Front Range OpenSolaris user
group last week), that having just one entry in the menu.lst file,
which boots the default bootable dataset, isn't adequate.  It is
necessary that users see the list of available BEs.  (actually,
there would have been two menu entries because there would
be a failsafe boot menu entry too, but that still doesn't get
you what LU does now with the GRUB menu).

This case is defining infrastructure for whatever choices
are made, management-wise and install-wise, in the area
of selecting the BE to be booted.  This case provides both
a way to define a default selection (the bootfs pool
property) and a way to specify alternate BEs (the bootfs
GRUB command). 

So, I take your point that the intended *use* of this
infrastructure should be corrected to recommend that
multiple menu.lst entries be provided, one for each BE.
But I believe that the core of this case, which is the
proposed interfaces and capabilities to be defined
for specifying the dataset to be booted, still stands as
adequate for the job.

Lori

From sacadmin Wed Mar 14 13:03:59 2007
Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75])
	by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2EK3wH8016765
	for <PSARC@sac.sfbay.sun.com>; Wed, 14 Mar 2007 13:03:58 -0700 (PDT)
Received: from [129.146.228.185] (dhcp-umpk17-228-185 [129.146.228.185])
	by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2EK3wn4011826;
	Wed, 14 Mar 2007 13:03:58 -0700 (PDT)
Message-ID: <45F8552D.5000508@sun.com>
Date: Wed, 14 Mar 2007 13:03:57 -0700
From: Matthew Ahrens <Matthew.Ahrens@sun.com>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Matthew Ahrens <ahrens@cyber.eng.sun.com>
CC: PSARC@sac.sfbay.sun.com, zfs-eng@sun.com
Subject: Re: ZFS bootable datasets [PSARC/2007/083 Timeout:  02/23/2007]
References: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
In-Reply-To: <200702082109.l18L9H5l005909@cyber.eng.sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Status: RO
Content-Length: 136

Matthew Ahrens wrote:
> Subject: PSARC FastTrack [02/23/2007]: ZFS bootable datasets

The case was approved at today's meeting.

--matt