From sacadmin Wed Mar 29 22:27:06 2006 Received: from cathy.eng.sun.com (cathy.SFBay.Sun.COM [129.146.228.63]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2U6R6IQ015057; Wed, 29 Mar 2006 22:27:06 -0800 (PST) Received: from cathy.eng.sun.com (localhost [127.0.0.1]) by cathy.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2U6R48e188219; Wed, 29 Mar 2006 22:27:04 -0800 (PST) Received: (from bonwick@localhost) by cathy.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2U6R48N188202; Wed, 29 Mar 2006 22:27:04 -0800 (PST) Date: Wed, 29 Mar 2006 22:27:04 -0800 (PST) From: Jeff Bonwick Message-Id: <200603300627.k2U6R48N188202@cathy.eng.sun.com> To: PSARC@sac.sfbay.sun.com Cc: eric.schrock@sun.com Subject: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Status: RO Content-Length: 5965 Subject: PSARC FastTrack [04/05/2006]: zpool upgrade Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI Copyright 2006 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: zpool upgrade 1.2. Name of Document Author/Supplier: Author: Eric Schrock 1.3 Date of This Document: 29 March, 2006 4. Technical Description This case requests a patch binding. As with the rest of zpool(1M), the subcommands and their options are Evolving, and the output is Unstable. A. DESCRIPTION It is anticipated that over the course of ZFS development, a need will arise to change the on-disk format. Prior to its release as supported software, this was dealt with by a suitable flag day. Moving forward, this is no longer acceptable. The user should still be able to use older versions of ZFS when possible, and upgrading to a newer version must be a deliberate act. While every attempt will be made to keep ZFS capable of reading and writing older on-disk versions, there may be changes which cannot be accomplished while maintaining this compatability. While no such changes are anticipated, the architecture is designed such that pools will appear as faulted, but can still be upgraded via an explicit action. B. NEW SUBCOMMANDS A new subcommand will be added to zpool(1M), 'zpool upgrade': zpool upgrade zpool upgrade -v zpool upgrade <-a | pool> The first form displays all pools formatted with a different on-disk version. The output of this command will show pools which are out of date as well as those with a newer version: # zpool upgrade This system is currently running ZFS version 2. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- ---------------------- 1 tank The following pools are formatted using a newer software version and cannot be accessed on the current system. VER POOL --- ----------------------- 3 dozer Use 'zpool upgrade -v' for a detailed description of supported versions and their associated features. If no pools are available for upgrade, the command simply prints a message and returns success. The second form of the command, 'zpool upgrade -v', displays a detailed list of supported on-disk versions, along with a description of the features each provides. A hypothetical example: # zpool upgrade -v This system is currently running ZFS version 2. The following versions are supported: VER DESCRIPTION --- --------------------------------------------------------------- 2 Provides metadata redundancy independent of pool configuration. Allows replication to be controlled on a per-filesystem basis using 'zfs set replication'. 1 Initial ZFS version. The final form of the command is used to upgrade pools on the system. If a particular pool is specified, then only that pool is upgraded. If '-a' is specified, then all currently out of date pools are upgraded. For example: # zpool upgrade -a This system is currently running ZFS version 2. Upgraded pool 'tank' Upgraded pool 'dozer' If all pools are running the current version, then 'zpool upgrade -a' does nothing, printing a message and returning sucess. If a pool is specified then only that pool is upgraded, and it is an error if the pool is already the latest version. C. CHANGES TO EXISTING SUBCOMMANDS The 'zpool status' output will be altered to understand when a pool is formatted with an older or newer version. If a pool is currently formatted using an older version, then 'zpool status' will display the pool as ONLINE, but the status will show that the pool is formatted using an older version, and the user should upgrade the pool in order to take advantage of the latest features. If a pool is formatted using a newer on-disk format version, then the pool will be faulted and 'zpool status' will indicate the pool is inaccessible, and recommend the user either access the pool from a system with newer software, or restore the pool from backup. The 'zpool import' subcommand will also be altered to display a warning when a pool is of an older version, but otherwise allow it to be imported. Pools formatted with a newer version will not be importable. D. MANPAGE CHANGES *************** *** 46,51 **** --- 46,57 ---- zpool import [-d dir] [-f] [-o opts] [-R root] [-a] + zpool upgrade + + zpool upgrade -v + + zpool upgrade <-a | pool> + DESCRIPTION The zpool command configures ZFS storage pools. A storage pool is a collection of devices that provides physical *************** *** 743,748 **** --- 749,781 ---- + zpool upgrade + + Displays all pools formatted using a different ZFS on- + disk version. Older versions can continue to be used, + but some feeatures may not be available. These pools + can be upgraded using 'zpool upgrade -a'. Pools + formatted with a more recent version are also displayed, + although these pools will be inaccessible on the + system. + + + zpool upgrade -v + + Display ZFS versions supported by the current software. + The current ZFS versions and all previous supported + versions are displayed, along with an explanation of the + features provided with each version. + + + zpool upgrade <-a | pool> + + Upgrades the given pool (or all pools if '-a' is + specified) to the latest on-disk version. Once this is + done, the pool will no longer be accessible on systems + running older versions of the software. + + EXAMPLES Example 1: Creating a RAID-Z ZFS Storage Pool 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 Mar 30 05:46:47 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UDklIQ003549 for ; Thu, 30 Mar 2006 05:46:47 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2UDkdcQ020136; Thu, 30 Mar 2006 08:46:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2UDkd7T020133; Thu, 30 Mar 2006 08:46:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17451.57662.979774.924786@gargle.gargle.HOWL> Date: Thu, 30 Mar 2006 08:46:38 -0500 From: James Carlson To: Jeff Bonwick Cc: PSARC@sac.sfbay.sun.com, eric.schrock@sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-Reply-To: Jeff Bonwick's message of 29 March 2006 22:27:04 References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1737 Jeff Bonwick writes: > The second form of the command, 'zpool upgrade -v', displays a detailed > list of supported on-disk versions, along with a description of the > features each provides. A hypothetical example: Other than remembering to run that command periodically, how does the user know that his system might have aging pools on it? Is there some way a warning could be automated? > If a pool is formatted using a newer on-disk format version, then the > pool will be faulted and 'zpool status' will indicate the pool is > inaccessible, and recommend the user either access the pool from a > system with newer software, or restore the pool from backup. What sort of magic decoder ring can be provided? For users with multiple boot environments, it'd probably be desirable to know ahead of time what the cut-off (introduction date) is for support of that pool version. In other words, if I upgrade now, how do I know which older boot environments am I breaking? How does this interact with ZFS as root and the upgrade process? If we have a pool for the root file system that's so old that it's unreadable, we'll likely have to force the pool upgrade just to do the scan for upgradeable Solaris images. That by itself causes a destructive catch-22: if the subsequent check for upgrade fails, the customer ends up with nothing. The old system can't run because the format has changed, and the new system doesn't install. (Doesn't this imply that the format needs to be committed, just like UFS?) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Mar 30 08:19:21 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UGJLIQ009728 for ; Thu, 30 Mar 2006 08:19:21 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2UGJK9j006396; Thu, 30 Mar 2006 08:19:20 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2UGJKZL006395; Thu, 30 Mar 2006 08:19:20 -0800 (PST) Date: Thu, 30 Mar 2006 08:19:20 -0800 From: Eric Schrock To: James Carlson Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060330161920.GC23671@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <17451.57662.979774.924786@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17451.57662.979774.924786@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2809 On Thu, Mar 30, 2006 at 08:46:38AM -0500, James Carlson wrote: > Jeff Bonwick writes: > > The second form of the command, 'zpool upgrade -v', displays a detailed > > list of supported on-disk versions, along with a description of the > > features each provides. A hypothetical example: > > Other than remembering to run that command periodically, how does the > user know that his system might have aging pools on it? Is there some > way a warning could be automated? Running 'zpool status -x' will show you any outdated pools. It was decided that it was not appropriate to generate an FMA fault for this case, since it's perfectly acceptable to run with an older version for long periods of time. Only when you want to use new features should it become apparent that you should upgrade - and any attempt to use such a feature on an older pool will display a message explaining this. > What sort of magic decoder ring can be provided? For users with > multiple boot environments, it'd probably be desirable to know ahead > of time what the cut-off (introduction date) is for support of that > pool version. In other words, if I upgrade now, how do I know which > older boot environments am I breaking? If there is some suitable way for describing when a bug was putback, I'd be all for it. But how does one describe a "supported release" when we have Solaris, Solaris Express, Community releases, OpenSolaris source, Nexenta, Schillix, etc? We also have an open RFE for the reverse: to store a string description of the version such that older versions will let you know what you need to run in order to read the pool. But it suffers from the same problem of how to adequately describe the version. One possible suggestion from that bug is to simply refer the user to a URL on opensolaris.org (http://www.opensolaris.org/os/community/zfs/versionX), which could give more information about which releases it applies. > How does this interact with ZFS as root and the upgrade process? If > we have a pool for the root file system that's so old that it's > unreadable, we'll likely have to force the pool upgrade just to do the > scan for upgradeable Solaris images. That by itself causes a > destructive catch-22: if the subsequent check for upgrade fails, the > customer ends up with nothing. The old system can't run because the > format has changed, and the new system doesn't install. We don't yet have a) supportable ZFS root, b) ZFS compatible upgrade, or c) an on-disk format change that necessitates offline migration, so I'm not sure I can answer this question definitively. I don't know much about how upgrade works, but this may force our hand in staying away from offline upgrade migration. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Thu Mar 30 09:16:03 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UHG3IQ011128 for ; Thu, 30 Mar 2006 09:16:03 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2UHFeWa028506; Thu, 30 Mar 2006 12:15:43 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2UHFYX5017334; Thu, 30 Mar 2006 12:15:35 -0500 (EST) Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] From: Bill Sommerfeld To: Jeff Bonwick Cc: PSARC@sac.sfbay.sun.com, Eric.Schrock@sun.com In-Reply-To: <200603300627.k2U6R48N188202@cathy.eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1143738933.17109.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 30 Mar 2006 12:15:34 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 991 > If all pools are running the current version, then 'zpool upgrade -a' does > nothing, printing a message and returning sucess. If a pool is > specified then only that pool is upgraded, and it is an error if the > pool is already the latest version. What's the rationale for having zpool upgrade -a succeed but zpool upgrade $pool fail in the no-op case? If I were going to be using this command in a script, having any upgrade "fail" because the upgrade had already happened would complicate error recovery significantly. Can you cite a use case where a user of this command would behave differently in the "already there" failure vs. the success case? If so, would it make sense to have distinct exit codes for "success", "already there", and "upgrade failed for other reason"? I'm assuming there are going to be other reasons why an upgrade could fail (for instance, i'd expect it to fail if pool is at version 3 when the latest the host can support is version 2). - Bill From sacadmin Thu Mar 30 09:34:39 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UHYdIQ011773 for ; Thu, 30 Mar 2006 09:34:39 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2UHYdOH007955; Thu, 30 Mar 2006 09:34:39 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2UHYc0V007954; Thu, 30 Mar 2006 09:34:38 -0800 (PST) Date: Thu, 30 Mar 2006 09:34:38 -0800 From: Eric Schrock To: Bill Sommerfeld Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060330173438.GB6938@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <1143738933.17109.38.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1143738933.17109.38.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1928 On Thu, Mar 30, 2006 at 12:15:34PM -0500, Bill Sommerfeld wrote: > > What's the rationale for having zpool upgrade -a succeed but zpool > upgrade $pool fail in the no-op case? If I were going to be using this > command in a script, having any upgrade "fail" because the upgrade had > already happened would complicate error recovery significantly. This is identical to the way that zpool mount/share work. If you are specifying 'zfs mount -a', it means "mount everything that needs to be mounted". If you do 'zfs mount ', it means "I have decided that this filesystem needs to be mounted, and if not then my assumption is flawed". For example: # zfs mount -a # zfs mount test cannot mount 'test': filesystem already mounted # echo $? 1 # This command is just following similar '-a' precedent in the other ZFS commands. That being said, I wouldn't fight to the death over this issue. > Can you cite a use case where a user of this command would behave > differently in the "already there" failure vs. the success case? > If so, would it make sense to have distinct exit codes for "success", > "already there", and "upgrade failed for other reason"? > > I'm assuming there are going to be other reasons why an upgrade could > fail (for instance, i'd expect it to fail if pool is at version 3 when > the latest the host can support is version 2). > At the moment, the 'upgrade process' is nothing more than setting a bit in an internal structure and letting sync to disk. The only way this can fail is if the user doesn't have permission or the on-disk version is newer. In the future, this process could be arbitrarily complex, and may fail for different reasons - perhaps all filesystems need to be unmounted for a particular upgrade, for example. Personally, I've never been a fan of multiple exit codes from commands. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Thu Mar 30 09:46:55 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UHksIQ012714 for ; Thu, 30 Mar 2006 09:46:55 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2UHkrm9021369; Thu, 30 Mar 2006 12:46:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2UHkrwh021366; Thu, 30 Mar 2006 12:46:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17452.6541.227595.940857@gargle.gargle.HOWL> Date: Thu, 30 Mar 2006 12:46:53 -0500 From: James Carlson To: Eric Schrock Cc: Bill Sommerfeld , Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-Reply-To: Eric Schrock's message of 30 March 2006 09:34:38 References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <1143738933.17109.38.camel@thunk> <20060330173438.GB6938@eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1568 Eric Schrock writes: > This is identical to the way that zpool mount/share work. If you are > specifying 'zfs mount -a', it means "mount everything that needs to be > mounted". If you do 'zfs mount ', it means "I have decided that > this filesystem needs to be mounted, and if not then my assumption is > flawed". For example: I think "mount" is a different sort of activity from "upgrade." With "mount," I'm asserting that this thing isn't currently mounted somewhere, and if it is, then I'm wrong and I need to know that, even if the operation would be a no-op. With "upgrade," I'm doing something slightly different. I'm asking to make sure that the object is in sync with the system. For that operation, I don't see why I'd want to assert that it is out of sync, or why it'd be an error if no work is required to bring it into sync. I don't quite see the usage case having "upgrade -a" fail because everything is actually just fine is helpful. > is newer. In the future, this process could be arbitrarily complex, and > may fail for different reasons - perhaps all filesystems need to be > unmounted for a particular upgrade, for example. Personally, I've never > been a fan of multiple exit codes from commands. Especially when the command can operate on multiple objects and end up returning different reasons for each. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Mar 30 09:51:49 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UHpnIQ012829 for ; Thu, 30 Mar 2006 09:51:49 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2UHpmq5008410; Thu, 30 Mar 2006 09:51:48 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2UHpmLp008409; Thu, 30 Mar 2006 09:51:48 -0800 (PST) Date: Thu, 30 Mar 2006 09:51:48 -0800 From: Eric Schrock To: James Carlson Cc: Bill Sommerfeld , Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060330175148.GD6938@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <1143738933.17109.38.camel@thunk> <20060330173438.GB6938@eng.sun.com> <17452.6541.227595.940857@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17452.6541.227595.940857@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1125 On Thu, Mar 30, 2006 at 12:46:53PM -0500, James Carlson wrote: > > I think "mount" is a different sort of activity from "upgrade." > > With "mount," I'm asserting that this thing isn't currently mounted > somewhere, and if it is, then I'm wrong and I need to know that, even > if the operation would be a no-op. > > With "upgrade," I'm doing something slightly different. I'm asking to > make sure that the object is in sync with the system. For that > operation, I don't see why I'd want to assert that it is out of sync, > or why it'd be an error if no work is required to bring it into sync. > > I don't quite see the usage case having "upgrade -a" fail because > everything is actually just fine is helpful. I don't think that anyone's advocating that "upgrade -a" should fail, only that "upgrade " shouldn't fail if the target is already the appropriate version (Bill, correct me if I'm wrong). If the opinion is that an explicit upgrade shouldn't fail in this case (as it seems to be), then I can amend the proposal. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Thu Mar 30 10:08:27 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UI8RIQ013504 for ; Thu, 30 Mar 2006 10:08:27 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2UI8PbB014776; Thu, 30 Mar 2006 13:08:25 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2UI8PI3017521; Thu, 30 Mar 2006 13:08:25 -0500 (EST) Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] From: Bill Sommerfeld To: Eric Schrock Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com In-Reply-To: <20060330173438.GB6938@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <1143738933.17109.38.camel@thunk> <20060330173438.GB6938@eng.sun.com> Content-Type: text/plain Message-Id: <1143742104.17109.93.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 30 Mar 2006 13:08:25 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1644 On Thu, 2006-03-30 at 12:34, Eric Schrock wrote: > This command is just following similar '-a' precedent in the other ZFS > commands. I'm not sure that really makes sense for "share" or "mount" either; seems like it's inherited behavior from the pre-ZFS world where "share" and "mount" take options affecting what sort of mount or share you want to do. Perhaps it was done that way (pre-ZFS) because a check for "already mounted" or "already shared" was straightforward, whereas a check to see whether the requested state was identical to the current state would add unnecessary complexity. But that's not the case for ZFS -- "zfs mount" and "zfs share" don't let you change mount or share properties as part of the command; you do that via the "set" subcommand.. (Note: the above is not a request to expand the scope of this proposal. I'm just thinking aloud here...) > Personally, I've never been a fan of multiple exit codes from commands. Neither have I, which I why I'd rather see a no-op upgrade succeed so a simple script could just plow onwards in that case. --- Also: I don't see an explicit statement about the stability level of command output relating to pool versions; "zpool upgrade" output appears to be intended for human consumption only and thus "not an interface". Assume I wanted to build an automated monitoring tool which signalled an alert when it spotted a below-revision pool on a system. What interface should I use? Is the stability of the command output sufficent to let me do that? zpool is specified as Evolving but we don't actually document its output format in the man page. - Bill From sacadmin Thu Mar 30 10:18:40 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UIIeIQ014018 for ; Thu, 30 Mar 2006 10:18:40 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2UIIegS009139; Thu, 30 Mar 2006 10:18:40 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2UIIeiH009138; Thu, 30 Mar 2006 10:18:40 -0800 (PST) Date: Thu, 30 Mar 2006 10:18:40 -0800 From: Eric Schrock To: Bill Sommerfeld Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060330181840.GE6938@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <1143738933.17109.38.camel@thunk> <20060330173438.GB6938@eng.sun.com> <1143742104.17109.93.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1143742104.17109.93.camel@thunk> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1354 On Thu, Mar 30, 2006 at 01:08:25PM -0500, Bill Sommerfeld wrote: > > Also: I don't see an explicit statement about the stability level of > command output relating to pool versions; "zpool upgrade" output appears > to be intended for human consumption only and thus "not an interface". That is correct. The command line interface is Evolving, but the output is unstable (or "not an interface"). > Assume I wanted to build an automated monitoring tool which signalled an > alert when it spotted a below-revision pool on a system. What interface > should I use? Is the stability of the command output sufficent to let > me do that? zpool is specified as Evolving but we don't actually > document its output format in the man page. No, consuming the command output is not stable. The only supported way to do this is to run "zpool status -x" and report when any pools have some kind of problem. If this is really a desirable feature, the right answer is to change the stability of libzfs (currently consolidation private), not to impose stability on zpool(1M) output. But I would not consider this a requirement, largely because we have yet to introduce a new version and have little to no idea about how users will deal with this change in the real world. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Thu Mar 30 10:25:08 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UIP8IQ014196 for ; Thu, 30 Mar 2006 10:25:08 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2UIP6bB020295; Thu, 30 Mar 2006 13:25:06 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2UIP68g017568; Thu, 30 Mar 2006 13:25:06 -0500 (EST) Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] From: Bill Sommerfeld To: Eric Schrock Cc: James Carlson , Jeff Bonwick , PSARC@sac.sfbay.sun.com In-Reply-To: <20060330161920.GC23671@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <17451.57662.979774.924786@gargle.gargle.HOWL> <20060330161920.GC23671@eng.sun.com> Content-Type: text/plain Message-Id: <1143743106.17109.119.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 30 Mar 2006 13:25:06 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1148 On Thu, 2006-03-30 at 11:19, Eric Schrock wrote: > > What sort of magic decoder ring can be provided? For users with > > multiple boot environments, it'd probably be desirable to know ahead > > of time what the cut-off (introduction date) is for support of that > > pool version. In other words, if I upgrade now, how do I know which > > older boot environments am I breaking? > > If there is some suitable way for describing when a bug was putback, I'd > be all for it. I think it would be sufficient if there was some way to tell from an installed boot environment (alternate root) which ZFS on-disk format versions it supported without booting it. (you'd then iterate over the BE's and compute a set intersection or equivalent). > We don't yet have a) supportable ZFS root, b) ZFS compatible upgrade, or > c) an on-disk format change that necessitates offline migration, so I'm > not sure I can answer this question definitively. I don't think (a) or (b) is actually relevant -- with boot/root in UFS and only data in ZFS it would be good to avoid accidentally precluding a fallback to an older BE if you can help it. - Bill From sacadmin Thu Mar 30 10:27:10 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UIRAIQ014259 for ; Thu, 30 Mar 2006 10:27:10 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2UIR9PJ021631; Thu, 30 Mar 2006 13:27:09 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2UIR9Ng021628; Thu, 30 Mar 2006 13:27:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17452.8957.114608.554124@gargle.gargle.HOWL> Date: Thu, 30 Mar 2006 13:27:09 -0500 From: James Carlson To: Eric Schrock Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-Reply-To: Eric Schrock's message of 30 March 2006 08:19:20 References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <17451.57662.979774.924786@gargle.gargle.HOWL> <20060330161920.GC23671@eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3540 Eric Schrock writes: > > Other than remembering to run that command periodically, how does the > > user know that his system might have aging pools on it? Is there some > > way a warning could be automated? > > Running 'zpool status -x' will show you any outdated pools. It was > decided that it was not appropriate to generate an FMA fault for this > case, since it's perfectly acceptable to run with an older version for > long periods of time. Only when you want to use new features should it > become apparent that you should upgrade - and any attempt to use such a > feature on an older pool will display a message explaining this. OK. I'm not positive all administrators will see it that way (isn't there some support risk in letting the bits rot?), but I guess that's getting off track for this review. > > What sort of magic decoder ring can be provided? For users with > > multiple boot environments, it'd probably be desirable to know ahead > > of time what the cut-off (introduction date) is for support of that > > pool version. In other words, if I upgrade now, how do I know which > > older boot environments am I breaking? > > If there is some suitable way for describing when a bug was putback, I'd > be all for it. But how does one describe a "supported release" when we > have Solaris, Solaris Express, Community releases, OpenSolaris source, > Nexenta, Schillix, etc? We also have an open RFE for the reverse: to > store a string description of the version such that older versions will > let you know what you need to run in order to read the pool. But it > suffers from the same problem of how to adequately describe the version. > One possible suggestion from that bug is to simply refer the user to a > URL on opensolaris.org > (http://www.opensolaris.org/os/community/zfs/versionX), which could give > more information about which releases it applies. That'd be great. I wasn't looking for more here than documentation; and a web page or even a blog would likely be sufficient. > > How does this interact with ZFS as root and the upgrade process? If > > we have a pool for the root file system that's so old that it's > > unreadable, we'll likely have to force the pool upgrade just to do the > > scan for upgradeable Solaris images. That by itself causes a > > destructive catch-22: if the subsequent check for upgrade fails, the > > customer ends up with nothing. The old system can't run because the > > format has changed, and the new system doesn't install. > > We don't yet have a) supportable ZFS root, b) ZFS compatible upgrade, or > c) an on-disk format change that necessitates offline migration, so I'm > not sure I can answer this question definitively. Sure; I know I'm asking to plan pretty far ahead. ;-} > I don't know much > about how upgrade works, but this may force our hand in staying away > from offline upgrade migration. OK. One of the reasons I ask the question is that, in the past, "we" (globally) have failed to consider upgrade implications until far too late in both project development and release schedules to handle the problem correctly, and the pain in sweeping up afterwards ends up being significant. And a bit personal. :-/ Just as advice here: it'd be good to work through some of those scenarios earlier rather than later. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Mar 30 11:46:33 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UJkXIQ016469 for ; Thu, 30 Mar 2006 11:46:33 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k2UJkRi8627596; Thu, 30 Mar 2006 11:46:32 -0800 (PST) Message-Id: <200603301946.k2UJkRi8627596@jurassic.eng.sun.com> Date: Thu, 30 Mar 2006 09:46:15 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] To: PSARC@sac.sfbay.sun.com, bonwick@cathy.eng.sun.com Cc: eric.schrock@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BiVvZ2xMmyRIRIHG9mGvAw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 7254 Two *minor* points: 1) Its going to seem strange to have this option if an incompatible change never happens. Have you considered not delivering (or maybe just not documenting) this until the first such change? 2) I know you aren't CLIPifying, but the opinion says we should always try to be consistent with the -V flag, which is version. Now, this flag typically is used to display a software version, not a version of a target database (ie: the on disk layout). Anyway, I think you should think about capitalizing the "v". If you decide not to, I'm fine with it. (Look at the justified RH margin. It just happened!) - jek3 > Date: Wed, 29 Mar 2006 22:27:04 -0800 (PST) > From: Jeff Bonwick > Subject: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] > To: PSARC@sac.sfbay.sun.com > Cc: eric.schrock@sun.com > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.1.2.240295 > > Subject: PSARC FastTrack [04/05/2006]: zpool upgrade > > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > Copyright 2006 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > zpool upgrade > 1.2. Name of Document Author/Supplier: > Author: Eric Schrock > 1.3 Date of This Document: > 29 March, 2006 > 4. Technical Description > This case requests a patch binding. As with the rest of zpool(1M), the > subcommands and their options are Evolving, and the output is Unstable. > > A. DESCRIPTION > > It is anticipated that over the course of ZFS development, a need will > arise to change the on-disk format. Prior to its release as supported > software, this was dealt with by a suitable flag day. Moving forward, > this is no longer acceptable. The user should still be able to use > older versions of ZFS when possible, and upgrading to a newer version > must be a deliberate act. > > While every attempt will be made to keep ZFS capable of reading and > writing older on-disk versions, there may be changes which cannot be > accomplished while maintaining this compatability. While no such > changes are anticipated, the architecture is designed such that pools > will appear as faulted, but can still be upgraded via an explicit > action. > > B. NEW SUBCOMMANDS > > A new subcommand will be added to zpool(1M), 'zpool upgrade': > > zpool upgrade > zpool upgrade -v > zpool upgrade <-a | pool> > > The first form displays all pools formatted with a different on-disk > version. The output of this command will show pools which are out of > date as well as those with a newer version: > > # zpool upgrade > This system is currently running ZFS version 2. > > The following pools are out of date, and can be upgraded. After > being upgraded, these pools will no longer be accessible by > older software versions. > > VER POOL > --- ---------------------- > 1 tank > > The following pools are formatted using a newer software version > and cannot be accessed on the current system. > > VER POOL > --- ----------------------- > 3 dozer > > Use 'zpool upgrade -v' for a detailed description of supported > versions and their associated features. > > If no pools are available for upgrade, the command simply prints a > message and returns success. > > The second form of the command, 'zpool upgrade -v', displays a detailed > list of supported on-disk versions, along with a description of the > features each provides. A hypothetical example: > > # zpool upgrade -v > This system is currently running ZFS version 2. The following > versions are supported: > > VER DESCRIPTION > --- --------------------------------------------------------------- > 2 Provides metadata redundancy independent of pool > configuration. Allows replication to be controlled on a > per-filesystem basis using 'zfs set replication'. > 1 Initial ZFS version. > > The final form of the command is used to upgrade pools on the system. > If a particular pool is specified, then only that pool is upgraded. If > '-a' is specified, then all currently out of date pools are upgraded. > For example: > > # zpool upgrade -a > This system is currently running ZFS version 2. > > Upgraded pool 'tank' > Upgraded pool 'dozer' > > If all pools are running the current version, then 'zpool upgrade -a' does > nothing, printing a message and returning sucess. If a pool is > specified then only that pool is upgraded, and it is an error if the > pool is already the latest version. > > C. CHANGES TO EXISTING SUBCOMMANDS > > The 'zpool status' output will be altered to understand when a pool is > formatted with an older or newer version. If a pool is currently > formatted using an older version, then 'zpool status' will display > the pool as ONLINE, but the status will show that the pool is formatted > using an older version, and the user should upgrade the pool in order to > take advantage of the latest features. > > If a pool is formatted using a newer on-disk format version, then the > pool will be faulted and 'zpool status' will indicate the pool is > inaccessible, and recommend the user either access the pool from a > system with newer software, or restore the pool from backup. > > The 'zpool import' subcommand will also be altered to display a warning > when a pool is of an older version, but otherwise allow it to be > imported. Pools formatted with a newer version will not be importable. > > D. MANPAGE CHANGES > > *************** > *** 46,51 **** > --- 46,57 ---- > > zpool import [-d dir] [-f] [-o opts] [-R root] [-a] > > + zpool upgrade > + > + zpool upgrade -v > + > + zpool upgrade <-a | pool> > + > DESCRIPTION > The zpool command configures ZFS storage pools. A storage > pool is a collection of devices that provides physical > *************** > *** 743,748 **** > --- 749,781 ---- > > > > + zpool upgrade > + > + Displays all pools formatted using a different ZFS on- > + disk version. Older versions can continue to be used, > + but some feeatures may not be available. These pools > + can be upgraded using 'zpool upgrade -a'. Pools > + formatted with a more recent version are also displayed, > + although these pools will be inaccessible on the > + system. > + > + > + zpool upgrade -v > + > + Display ZFS versions supported by the current software. > + The current ZFS versions and all previous supported > + versions are displayed, along with an explanation of the > + features provided with each version. > + > + > + zpool upgrade <-a | pool> > + > + Upgrades the given pool (or all pools if '-a' is > + specified) to the latest on-disk version. Once this is > + done, the pool will no longer be accessible on systems > + running older versions of the software. > + > + > > EXAMPLES > Example 1: Creating a RAID-Z ZFS Storage Pool > > 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 Mar 30 11:57:17 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UJvHIQ017022 for ; Thu, 30 Mar 2006 11:57:17 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k2UJvFo6022496; Thu, 30 Mar 2006 14:57:15 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k2UJvFsI022493; Thu, 30 Mar 2006 14:57:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17452.14363.47516.465880@gargle.gargle.HOWL> Date: Thu, 30 Mar 2006 14:57:15 -0500 From: James Carlson To: Joseph Kowalski Cc: PSARC@sac.sfbay.sun.com, bonwick@cathy.eng.sun.com, eric.schrock@sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-Reply-To: Joseph Kowalski's message of 30 March 2006 09:46:15 References: <200603301946.k2UJkRi8627596@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1441 Joseph Kowalski writes: > > Two *minor* points: > > 1) Its going to seem strange to have this option if an incompatible > change never happens. Have you considered not delivering (or maybe > just not documenting) this until the first such change? Maybe. Actually, I think it's kind of nice. UFS has had these speedbumps in the past, and we just went into forward-migration-only (with warnings) mode. This solution is better. You can migrate forward when you're sure you don't want want to revert, rather than being forced to just because the version is new in the upgrade. > 2) I know you aren't CLIPifying, but the opinion says we should always > try to be consistent with the -V flag, which is version. Now, this > flag typically is used to display a software version, not a version > of a target database (ie: the on disk layout). Anyway, I think you > should think about capitalizing the "v". If you decide not to, I'm > fine with it. That doesn't sound quite right to me. I'd be surprised to get anything other than the version of the tool itself from "-V". (In fact, I'd expect -V to tell me what versions were supported by the OS, not what versions happened to be on the disk.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Mar 30 12:51:04 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UKp4IQ019338 for ; Thu, 30 Mar 2006 12:51:04 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2UKp3TD012633; Thu, 30 Mar 2006 12:51:03 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2UKp3LO012632; Thu, 30 Mar 2006 12:51:03 -0800 (PST) Date: Thu, 30 Mar 2006 12:51:03 -0800 From: Eric Schrock To: James Carlson Cc: Joseph Kowalski , PSARC@sac.sfbay.sun.com, bonwick@cathy.eng.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060330205103.GH6938@eng.sun.com> References: <200603301946.k2UJkRi8627596@jurassic.eng.sun.com> <17452.14363.47516.465880@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17452.14363.47516.465880@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2082 On Thu, Mar 30, 2006 at 02:57:15PM -0500, James Carlson wrote: > Joseph Kowalski writes: > > > > Two *minor* points: > > > > 1) Its going to seem strange to have this option if an incompatible > > change never happens. Have you considered not delivering (or maybe > > just not documenting) this until the first such change? > > Maybe. Actually, I think it's kind of nice. UFS has had these > speedbumps in the past, and we just went into forward-migration-only > (with warnings) mode. > > This solution is better. You can migrate forward when you're sure you > don't want want to revert, rather than being forced to just because > the version is new in the upgrade. Yes. The point is to try and get this into customer hands early (preferably in S10U2) prior to actually delivering the first incompatible version. This way they have a sensible error message, diagnosis, and instructions about how to upgrade should they encounter a future version. If we wait until the first incompatible change, the behavior is going to be inconsistent with those customers who don't yet have this feature. > > > 2) I know you aren't CLIPifying, but the opinion says we should always > > try to be consistent with the -V flag, which is version. Now, this > > flag typically is used to display a software version, not a version > > of a target database (ie: the on disk layout). Anyway, I think you > > should think about capitalizing the "v". If you decide not to, I'm > > fine with it. > > That doesn't sound quite right to me. I'd be surprised to get > anything other than the version of the tool itself from "-V". (In > fact, I'd expect -V to tell me what versions were supported by the OS, > not what versions happened to be on the disk.) Yes, I've though about having "zpool -V" be an alias to a shortened form of "zpool upgrade -v" that would show just the current version, but I don't feel too strongly about it. Changing it to "zpool upgrade -V" can also be done. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Thu Mar 30 13:05:40 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2UL5eIQ021115 for ; Thu, 30 Mar 2006 13:05:40 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with SMTP id k2UL5PmN706783; Thu, 30 Mar 2006 13:05:31 -0800 (PST) Message-Id: <200603302105.k2UL5PmN706783@jurassic.eng.sun.com> Date: Thu, 30 Mar 2006 11:05:15 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] To: james.d.carlson@sun.com, eric.schrock@sun.com Cc: Joseph.Kowalski@eng.sun.com, PSARC@sac.sfbay.sun.com, bonwick@cathy.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uIWYfq168Dhgk/Ovj51JlQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1138 > From: Eric Schrock ... > > > 2) I know you aren't CLIPifying, but the opinion says we should always > > > try to be consistent with the -V flag, which is version. Now, this > > > flag typically is used to display a software version, not a version > > > of a target database (ie: the on disk layout). Anyway, I think you > > > should think about capitalizing the "v". If you decide not to, I'm > > > fine with it. > > > > That doesn't sound quite right to me. I'd be surprised to get > > anything other than the version of the tool itself from "-V". (In > > fact, I'd expect -V to tell me what versions were supported by the OS, > > not what versions happened to be on the disk.) > > Yes, I've though about having "zpool -V" be an alias to a shortened form > of "zpool upgrade -v" that would show just the current version, but I > don't feel too strongly about it. Changing it to "zpool upgrade -V" can > also be done. I was just making sure you'ld thought about it. As noted in my original comment, I wasn't too sure this applied and I think I agree with Jim. Let's leave it as is. - jek3 From sacadmin Fri Mar 31 11:21:11 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2VJLBIQ024237 for ; Fri, 31 Mar 2006 11:21:11 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2VJLALT014264; Fri, 31 Mar 2006 11:21:10 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2VJLAKK014263; Fri, 31 Mar 2006 11:21:10 -0800 (PST) Date: Fri, 31 Mar 2006 11:21:10 -0800 From: Eric Schrock To: Jeff Bonwick Cc: PSARC@sac.sfbay.sun.com Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060331192110.GE11507@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603300627.k2U6R48N188202@cathy.eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 5963 Below you can find the updated spec. It includes the following changes based on feedback: * Clarified that all expected upgrades are online and instantaneous * Adding reference to ZFS community in 'zpool upgrade -v' output. * 'zpool upgrade ' should not be an error if it is already up to date. * Clarified that 'zpool status -x' will identify outdated pools. - Eric A. DESCRIPTION It is anticipated that over the course of ZFS development, a need will arise to change the on-disk format. Prior to its release as supported software, this was dealt with by a suitable flag day. Moving forward, this is no longer acceptable. The user should still be able to use older versions of ZFS when possible, and upgrading to a newer version must be a deliberate act. It is expected that all future upgrades will be online and instantaneous. However, there may be changes which cannot be accomplished while maintaining this compatability. While no such changes are anticipated, the architecture is designed such that pools will appear as faulted, but can still be upgraded via an explicit action. B. NEW SUBCOMMANDS A new subcommand will be added to zpool(1M), 'zpool upgrade': zpool upgrade zpool upgrade -v zpool upgrade <-a | pool> The first form displays all pools formatted with a different on-disk version. The output of this command will show pools which are out of date as well as those with a newer version: # zpool upgrade This system is currently running ZFS version 2. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- ---------------------- 1 tank The following pools are formatted using a newer software version and cannot be accessed on the current system. VER POOL --- ----------------------- 3 dozer Use 'zpool upgrade -v' for a detailed description of supported versions and their associated features. If no pools are available for upgrade, the command simply prints a message and returns success. The second form of the command, 'zpool upgrade -v', displays a detailed list of supported on-disk versions, along with a description of the features each provides. A hypothetical example: # zpool upgrade -v This system is currently running ZFS version 2. The following versions are supported: VER DESCRIPTION --- --------------------------------------------------------- 2 Provides metadata redundancy independent of pool configuration. Allows replication to be controlled on a per-filesystem basis using 'zfs set replication'. 1 Initial ZFS version. For a more detailed description of a particular ZFS version, including which releases support it, see: http://www.opensolaris.org/os/community/zfs/version/X Where 'X' is the version number. The final form of the command is used to upgrade pools on the system. If a particular pool is specified, then only that pool is upgraded. If '-a' is specified, then all currently out of date pools are upgraded. For example: # zpool upgrade -a This system is currently running ZFS version 2. Upgraded pool 'tank' Upgraded pool 'dozer' If all pools are running the current version, then 'zpool upgrade -a' does nothing, printing a message and returning sucess. If a pool is specified then only that pool is upgraded. If the pool is already using the current version, then a message is printed and the command returns success. C. CHANGES TO EXISTING SUBCOMMANDS The 'zpool status' output will be altered to understand when a pool is formatted with an older or newer version. If a pool is currently formatted using an older version, then 'zpool status' will display the pool as ONLINE, but the status will show that the pool is formatted using an older version, and the user should upgrade the pool in order to take advantage of the latest features. Outdated pools will be identified when running 'zpool status -x'. If a pool is formatted using a newer on-disk format version, then the pool will be faulted and 'zpool status' will indicate the pool is inaccessible, and recommend the user either access the pool from a system with newer software, or restore the pool from backup. The 'zpool import' subcommand will also be altered to display a warning when a pool is of an older version, but otherwise allow it to be imported. Pools formatted with a newer version will not be importable. D. MANPAGE CHANGES *************** *** 46,51 **** --- 46,57 ---- zpool import [-d dir] [-f] [-o opts] [-R root] [-a] + zpool upgrade + + zpool upgrade -v + + zpool upgrade <-a | pool> + DESCRIPTION The zpool command configures ZFS storage pools. A storage pool is a collection of devices that provides physical *************** *** 743,748 **** --- 749,781 ---- + zpool upgrade + + Displays all pools formatted using a different ZFS on- + disk version. Older versions can continue to be used, + but some feeatures may not be available. These pools + can be upgraded using 'zpool upgrade -a'. Pools + formatted with a more recent version are also displayed, + although these pools will be inaccessible on the + system. + + + zpool upgrade -v + + Display ZFS versions supported by the current software. + The current ZFS versions and all previous supported + versions are displayed, along with an explanation of the + features provided with each version. + + + zpool upgrade <-a | pool> + + Upgrades the given pool (or all pools if '-a' is + specified) to the latest on-disk version. Once this is + done, the pool will no longer be accessible on systems + running older versions of the software. + + EXAMPLES Example 1: Creating a RAID-Z ZFS Storage Pool From sacadmin Fri Mar 31 12:35:02 2006 Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2VKZ2IQ026578 for ; Fri, 31 Mar 2006 12:35:02 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IX000201EB3CP@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 31 Mar 2006 12:35:02 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-27-200.SFBay.Sun.COM [129.150.27.200]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IX000AS9EID67@mpk-mail1.sfbay.sun.com>; Fri, 31 Mar 2006 12:35:02 -0800 (PST) Date: Fri, 31 Mar 2006 12:35:02 -0800 From: Ed Gould Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-reply-to: <20060331192110.GE11507@eng.sun.com> To: Eric Schrock Cc: PSARC@sac.sfbay.sun.com, Jeff Bonwick Message-id: MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <20060331192110.GE11507@eng.sun.com> Status: RO Content-Length: 310 On Mar 31, 2006, at 11:21, Eric Schrock wrote: > Below you can find the updated spec. ... > zpool upgrade <-a | pool> Sorry I didn't notice this sooner, but why not zpool upgrade <-a | pool...> ? In other words, why limit to one explicitly-named pool and not as many as the user cares to list? --Ed From sacadmin Fri Mar 31 13:09:10 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2VL9AIQ028098 for ; Fri, 31 Mar 2006 13:09:10 -0800 (PST) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id k2VL999v017247; Fri, 31 Mar 2006 13:09:09 -0800 (PST) Received: (from eschrock@localhost) by zion.eng.sun.com (8.13.3+Sun/8.13.3/Submit) id k2VL99iA017246; Fri, 31 Mar 2006 13:09:09 -0800 (PST) Date: Fri, 31 Mar 2006 13:09:09 -0800 From: Eric Schrock To: Ed Gould Cc: PSARC@sac.sfbay.sun.com, Jeff Bonwick Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] Message-ID: <20060331210908.GG11507@eng.sun.com> References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <20060331192110.GE11507@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 430 On Fri, Mar 31, 2006 at 12:35:02PM -0800, Ed Gould wrote: > > Sorry I didn't notice this sooner, but why not > > zpool upgrade <-a | pool...> > > ? In other words, why limit to one explicitly-named pool and not as > many as the user cares to list? > No reason, just a typo in the spec. The prototype actually allows multiple pools. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock From sacadmin Fri Mar 31 15:10:39 2006 Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2VNAdIQ002116 for ; Fri, 31 Mar 2006 15:10:39 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IX000C01LLAC6@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 31 Mar 2006 15:10:39 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-22-146.SFBay.Sun.COM [129.150.22.146]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IX0009QQLPHZ8@mpk-mail1.sfbay.sun.com>; Fri, 31 Mar 2006 15:10:29 -0800 (PST) Date: Fri, 31 Mar 2006 15:10:29 -0800 From: Ed Gould Subject: Re: zpool upgrade [PSARC/2006/206 Timeout: 04/05/2006] In-reply-to: <20060331210908.GG11507@eng.sun.com> To: Eric Schrock Cc: PSARC@sac.sfbay.sun.com, Jeff Bonwick Message-id: <6b0a2c6933d97732756b3ca3d5634223@sun.com> MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200603300627.k2U6R48N188202@cathy.eng.sun.com> <20060331192110.GE11507@eng.sun.com> <20060331210908.GG11507@eng.sun.com> Status: RO Content-Length: 419 On Mar 31, 2006, at 13:09, Eric Schrock wrote: > On Fri, Mar 31, 2006 at 12:35:02PM -0800, Ed Gould wrote: >> >> Sorry I didn't notice this sooner, but why not >> >> zpool upgrade <-a | pool...> >> >> ? In other words, why limit to one explicitly-named pool and not as >> many as the user cares to list? >> > > No reason, just a typo in the spec. The prototype actually allows > multiple pools. Ah. Ok. --Ed From sacadmin Wed Apr 12 08:11:00 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k3CFAxIQ007346 for ; Wed, 12 Apr 2006 08:10:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k3CFAgvn028532 for <@sunmail3.sfbay.sun.com:psarc@Sun.COM>; Wed, 12 Apr 2006 23:10:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IXM00B0B7I7EY00@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@sun.com); Wed, 12 Apr 2006 08:10:55 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IXM004HE7I7DUD0@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@sun.com); Wed, 12 Apr 2006 08:10:55 -0700 (PDT) Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3CFAtpK000502 for ; Wed, 12 Apr 2006 08:10:55 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IXM00F017GCUL@mpk-mail1.sfbay.sun.com> (original mail from Sherri.Shieh@Sun.COM) for psarc@sun.com; Wed, 12 Apr 2006 08:10:55 -0700 (PDT) Received: from [129.146.11.196] (sr1-umpk-16.SFBay.Sun.COM [129.146.11.196]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IXM000KB7I6AW@mpk-mail1.sfbay.sun.com>; Wed, 12 Apr 2006 08:10:55 -0700 (PDT) Date: Wed, 12 Apr 2006 08:10:54 -0700 From: Sherri Shieh Subject: PSARC Fast track: 2006/206 zpool upgrade To: psarc@sun.com, Jeff Bonwick , Eric.Schrock@sun.com Message-id: <443D187E.7030503@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 353 This fast track was approved in last week's meeting. I have marked it as approved. - Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 ===========================================================