From Tim.Haley@sun.com Wed Sep 9 20:48:07 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8A3m6Cx012440 for ; Wed, 9 Sep 2009 20:48:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8A3m3th003702; Wed, 9 Sep 2009 20:48:06 -0700 (PDT) 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 <0KPQ00I0VL84NR00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 20:48:04 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ00322L83S280@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 20:48:04 -0700 (PDT) Received: from spidey.local (spidey.Central.Sun.COM [172.20.25.27]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8A3m3Yh024432; Wed, 09 Sep 2009 21:48:03 -0600 (MDT) Received: from spidey.local (localhost [127.0.0.1]) by spidey.local (8.14.3+Sun/8.14.3) with ESMTP id n8A3eX1Y023663; Wed, 09 Sep 2009 21:40:33 -0600 (MDT) Received: (from timh@localhost) by spidey.local (8.14.3+Sun/8.14.3/Submit) id n8A3eXmo023660; Wed, 09 Sep 2009 21:40:33 -0600 (MDT) Date: Wed, 09 Sep 2009 21:40:33 -0600 (MDT) From: Tim Haley Subject: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] To: PSARC-ext@sun.com Cc: zfs-team@sun.com Message-id: <200909100340.n8A3eXmo023660@spidey.local> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7854 I am sponsoring the following fast-track for myself. This case introduces additional zpool sub-command options to support pool recovery. The case is requesting micro/patch binding. Timeout is 09/16/2009. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: zpool recovery support 1.2. Name of Document Author/Supplier: Author: Timothy Haley 1.3 Date of This Document: 09 September, 2009 4. Technical Description OVERVIEW: Uncooperative or deceptive hardware, combined with power failures or sudden lack of access to devices, can result in zpools without redundancy being non-importable. ZFS' copy-on-write and Merkle tree properties will sometimes allow us to recover from these problems. Only ad-hoc means currently exist to take advantage of this recoverability. This proposal aims to rectify that short-coming. PROPOSED SOLUTION: This fast-track proposes two new command line flags each for the 'zpool clear' and 'zpool import' sub-commands. Both sub-commands will now accept a '-F' recovery mode flag. When specified, a determination is made if discarding the last few transactions performed in an unopenable or non-importable pool will return the pool to an usable state. If so, the transactions are irreversibly discarded, and the pool imported. If the pool is usable or already imported and this flag is specified, the flag is ignored and no transactions are discarded. Both sub-commands will now also accept a '-n' flag. This flag is only meaningful in conjunction with the '-F' flag. When specified, an attempt is made to see if discarding transactions will return the pool to a usable state, but no transactions are actually discarded. PROPOSED CHANGES to ZPOOL(1M) PAGE: --- zpool.1m.rogi Thu Aug 27 09:59:14 2009 +++ zpool.1m Wed Sep 9 21:02:25 2009 @@ -18,7 +18,7 @@ zpool attach [-f] pool device new_device - zpool clear pool [device] + zpool clear [-n] [-F] pool [device] zpool create [-fn] [-o property=value] ... [-O file-system-property=value] @@ -44,11 +44,11 @@ zpool import [-o mntopts] [-p property=value] ... [-d dir | -c cachefile] - [-D] [-f] [-R root] -a + [-D] [-f] [-R root] [-n] [-F] -a zpool import [-o mntopts] [-o property=value] ... [-d dir | -c cachefile] - [-D] [-f] [-R root] pool |id [newpool] + [-D] [-f] [-R root] [-n] [-F] pool |id [newpool] zpool iostat [-v] [pool] ... [interval[count]] @@ -761,7 +761,7 @@ - zpool clear pool [device] ... + zpool clear [-n] [-F] pool [device] ... Clears device errors in a pool. If no arguments are specified, all device errors within the pool are @@ -769,7 +769,18 @@ errors associated with the specified device or devices are cleared. + -F Initiates recovery mode for a unopenable pool. + Attempts to discard the last few transactions in the + pool to return it to an openable state. Not all + damaged pools can be recovered by using this option. + If successful, the data from the discarded transactions + is irreversibly lost. + -n Used in combination with the -F flag. Check if + discarding transactions would make the pool openable, + but do not actually discard any transactions. + + zpool create [-fn] [-o property=value] ... [-O file-system- property=value] ... [-m mountpoint] [-R root] pool vdev ... @@ -1016,7 +1027,7 @@ zpool import [-o mntopts] [ -o property=value] ... [-d dir | - -c cachefile] [-D] [-f] [-R root] -a + -c cachefile] [-D] [-f] [-n] [-F] [-R root] -a Imports all pools found in the search directories. Identical to the previous command, except that all pools @@ -1075,6 +1086,17 @@ appears to be potentially active. + -F Recovery mode for a non-importable pool. + Attempt to return the pool to an + importable state by discarding the last + few transactions. Not all damaged pools + can be recovered by using this option. + If successful, the data from the + discarded transactions is irreversibly + lost. This option is ignored if the pool + is importable or already imported. + + -a Searches for and imports all pools found. @@ -1083,10 +1105,17 @@ "none" and the "altroot" property to "root". + -n Used with the -F recovery option. + Determines if a non-importable pool + can be made importable again, but does not + actually perform the pool recovery. For + more details about pool recovery mode, + see the -F option. + zpool import [-o mntopts] [ -o property=value] ... [-d dir | - -c cachefile] [-D] [-f] [-R root] pool | id [newpool] + -c cachefile] [-D] [-f] [-R root] [-F] [-n] pool | id [newpool] Imports a specific pool. A pool can be identified by its name or the numeric identifier. If newpool is specified, @@ -1153,6 +1182,17 @@ tially active. + -F + + Recovery mode for a non-importable pool. Attempt to + return the pool to an importable state by discarding the + last few transactions. Not all damaged pools can be + recovered by using this option. If successful, the data + from the discarded transactions is irreversibly lost. + This option is ignored if the pool is importable or + already imported. + + -R root Sets the "cachefile" property to "none" and the @@ -1159,7 +1199,15 @@ "altroot" property to "root". + -n + Used with the -F recovery mode option. Determines if a + non-importable pool can be made importable again, but + does not actually perform the pool recovery. For more + details about pool recovery mode, see the -F option. + + + zpool iostat [-v] [pool] ... [interval[count]] Displays I/O statistics for the given pools. When given @@ -1669,7 +1717,27 @@ # zpool iostat -v pool 5 + Example 14 Recovering a faulted ZFS pool + If a pool is faulted but recoverable, a message indicating so is + provided by 'zpool status' if the pool was cached (see cachefile + above), or as part of the error output from a failed 'zpool + import' of the pool. + + Recover a cached pool with the zpool clear command: + + # zpool clear -F data + Pool data returned to its state as of Tue Sep 08 13:23:35 2009. + Discarded approximately 29 seconds of transactions. + + If the pool configuration was not cached, use zpool import + with the recovery mode flag: + + # zpool import -F data + Pool data returned to its state as of Tue Sep 08 13:23:35 2009. + Discarded approximately 29 seconds of transactions. + + EXIT STATUS The following exit values are returned: 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Scott.Rotondo@sun.com Wed Sep 9 21:08:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8A48io1016674 for ; Wed, 9 Sep 2009 21:08:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8A48bL9025813; Thu, 10 Sep 2009 05:08:43 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPQ00J01M6ILN00@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 22:08:42 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ009D7M6I05B0@brm-avmta-1.central.sun.com>; Wed, 09 Sep 2009 22:08:42 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8A48gUK004659; Thu, 10 Sep 2009 04:08:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPQ00K00LWZJM00@mail-amer.sun.com>; Wed, 09 Sep 2009 22:08:42 -0600 (MDT) Received: from viaggio.local ([unknown] [69.226.245.59]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPQ00JF8M6HS210@mail-amer.sun.com>; Wed, 09 Sep 2009 22:08:42 -0600 (MDT) Date: Wed, 09 Sep 2009 21:08:46 -0700 From: Scott Rotondo Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <200909100340.n8A3eXmo023660@spidey.local> Sender: Scott.Rotondo@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AA87BCE.3060508@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 1335 Tim Haley wrote: > > PROPOSED SOLUTION: > > This fast-track proposes two new command line flags each for > the 'zpool clear' and 'zpool import' sub-commands. > > Both sub-commands will now accept a '-F' recovery mode flag. > When specified, a determination is made if discarding the last > few transactions performed in an unopenable or non-importable > pool will return the pool to an usable state. If so, the > transactions are irreversibly discarded, and the pool > imported. If the pool is usable or already imported and this > flag is specified, the flag is ignored and no transactions are > discarded. > > Both sub-commands will now also accept a '-n' flag. This flag > is only meaningful in conjunction with the '-F' flag. When > specified, an attempt is made to see if discarding transactions > will return the pool to a usable state, but no transactions are > actually discarded. Here's a usability suggestion. Whenever clear or import fails, why not automatically do the equivalent of -F -n (i.e. tell the user if recovery is possible)? If so, the user can invoke with -F if desired. There would be no need to create a -n option. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From tim.haley@sun.com Wed Sep 9 21:45:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8A4jbtf016858 for ; Wed, 9 Sep 2009 21:45:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8A4jXSV016540; Thu, 10 Sep 2009 05:45:36 +0100 (BST) 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 <0KPQ00M09NVYX100@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 21:45:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ003WHNVYS290@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Sep 2009 21:45:34 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8A4jYAv021861; Thu, 10 Sep 2009 04:45:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPQ00J00NJBMY00@mail-amer.sun.com>; Wed, 09 Sep 2009 22:45:34 -0600 (MDT) Received: from Giles.local ([unknown] [71.196.247.195]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPQ00HXQNVVVW10@mail-amer.sun.com>; Wed, 09 Sep 2009 22:45:31 -0600 (MDT) Date: Wed, 09 Sep 2009 22:45:30 -0600 From: Tim Haley Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <4AA87BCE.3060508@sun.com> Sender: Timothy.Haley@sun.com To: Scott Rotondo Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AA8846A.3070504@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> <4AA87BCE.3060508@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 1389 Scott Rotondo wrote: > Tim Haley wrote: >> >> PROPOSED SOLUTION: >> >> This fast-track proposes two new command line flags each for >> the 'zpool clear' and 'zpool import' sub-commands. >> >> Both sub-commands will now accept a '-F' recovery mode flag. >> When specified, a determination is made if discarding the last >> few transactions performed in an unopenable or non-importable >> pool will return the pool to an usable state. If so, the >> transactions are irreversibly discarded, and the pool >> imported. If the pool is usable or already imported and this >> flag is specified, the flag is ignored and no transactions are >> discarded. >> >> Both sub-commands will now also accept a '-n' flag. This flag >> is only meaningful in conjunction with the '-F' flag. When >> specified, an attempt is made to see if discarding transactions >> will return the pool to a usable state, but no transactions are >> actually discarded. > > Here's a usability suggestion. Whenever clear or import fails, why not > automatically do the equivalent of -F -n (i.e. tell the user > if recovery is possible)? If so, the user can invoke with -F if desired. > There would be no need to create a -n option. > That is exactly how it works in the prototype. The -n is still useful for reconfirming. -tim > Scott > > From Scott.Rotondo@sun.com Wed Sep 9 22:04:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8A54MwG017516 for ; Wed, 9 Sep 2009 22:04:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8A54DnH020434; Thu, 10 Sep 2009 13:04:21 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPQ00903OR7E800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 22:04:19 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ00DV7OR7G1A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Sep 2009 22:04:19 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8A54JIo002818; Thu, 10 Sep 2009 05:04:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPQ00300OGPFZ00@mail-amer.sun.com>; Wed, 09 Sep 2009 23:04:18 -0600 (MDT) Received: from viaggio.local ([unknown] [10.7.251.213]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPQ00HW8OR6VW40@mail-amer.sun.com>; Wed, 09 Sep 2009 23:04:18 -0600 (MDT) Date: Wed, 09 Sep 2009 22:04:24 -0700 From: Scott Rotondo Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <4AA8846A.3070504@sun.com> Sender: Scott.Rotondo@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AA888D8.3050001@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> <4AA87BCE.3060508@sun.com> <4AA8846A.3070504@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 1718 Tim Haley wrote: > Scott Rotondo wrote: >> Tim Haley wrote: >>> >>> PROPOSED SOLUTION: >>> >>> This fast-track proposes two new command line flags each for >>> the 'zpool clear' and 'zpool import' sub-commands. >>> >>> Both sub-commands will now accept a '-F' recovery mode flag. >>> When specified, a determination is made if discarding the last >>> few transactions performed in an unopenable or non-importable >>> pool will return the pool to an usable state. If so, the >>> transactions are irreversibly discarded, and the pool >>> imported. If the pool is usable or already imported and this >>> flag is specified, the flag is ignored and no transactions are >>> discarded. >>> >>> Both sub-commands will now also accept a '-n' flag. This flag >>> is only meaningful in conjunction with the '-F' flag. When >>> specified, an attempt is made to see if discarding transactions >>> will return the pool to a usable state, but no transactions are >>> actually discarded. >> >> Here's a usability suggestion. Whenever clear or import fails, why not >> automatically do the equivalent of -F -n (i.e. tell the user >> if recovery is possible)? If so, the user can invoke with -F if >> desired. There would be no need to create a -n option. >> > That is exactly how it works in the prototype. > > The -n is still useful for reconfirming. > > -tim > OK, good. I'm less concerned about removing the -n than I am about making sure we automatically tell the user when he should try -F. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From Darren.Moffat@Sun.COM Thu Sep 10 01:57:12 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8A8vB2b004709 for ; Thu, 10 Sep 2009 01:57:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8A8vBvr010721; Thu, 10 Sep 2009 01:57:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPQ00G03ZJBXQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 01:57:11 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPQ006TWZJAXL80@nwk-avmta-1.sfbay.Sun.COM>; Thu, 10 Sep 2009 01:57:11 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8A8v9Ys004787; Thu, 10 Sep 2009 08:57:09 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPQ00B00Z68NP00@fe-emea-10.sun.com>; Thu, 10 Sep 2009 09:56:58 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPQ00GJLZIS3ZC0@fe-emea-10.sun.com>; Thu, 10 Sep 2009 09:56:53 +0100 (BST) Date: Thu, 10 Sep 2009 09:56:52 +0100 From: Darren J Moffat Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <200909100340.n8A3eXmo023660@spidey.local> Sender: Darren.Moffat@Sun.COM To: Tim Haley Cc: PSARC-ext@Sun.COM, zfs-team@Sun.COM Message-id: <4AA8BF54.9010308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 893 Tim Haley wrote: > I am sponsoring the following fast-track for myself. This case > introduces additional zpool sub-command options to support pool > recovery. The case is requesting micro/patch binding. Timeout is > 09/16/2009. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > zpool recovery support > 1.2. Name of Document Author/Supplier: > Author: Timothy Haley > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description I'm happy with the case as specified so it gets my +1. I'm going on the assumption that there are spa history records written for this - but didn't expect to see that as part of the ARC material since their format isn't an interface and many of them are Internal taxonomy anyway. -- Darren J Moffat From Sebastien.Roy@sun.com Thu Sep 10 06:53:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8ADrTML023218 for ; Thu, 10 Sep 2009 06:53:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8ADrS4Z005293; Thu, 10 Sep 2009 06:53:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPR00B0JD934Q00@brm-avmta-1.central.sun.com>; Thu, 10 Sep 2009 07:53:27 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPR00B43D900I00@brm-avmta-1.central.sun.com>; Thu, 10 Sep 2009 07:53:24 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8ADrOjo007961; Thu, 10 Sep 2009 13:53:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPR00900D5UMG00@mail-amer.sun.com>; Thu, 10 Sep 2009 07:53:24 -0600 (MDT) Received: from [192.168.1.2] ([unknown] [173.76.19.212]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPR005QMD8NZO10@mail-amer.sun.com>; Thu, 10 Sep 2009 07:53:12 -0600 (MDT) Date: Thu, 10 Sep 2009 09:53:11 -0400 From: Sebastien Roy Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <200909100340.n8A3eXmo023660@spidey.local> Sender: Sebastien.Roy@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <1252590791.2279.55.camel@seb> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> Status: RO Content-Length: 279 On Wed, 2009-09-09 at 21:40 -0600, Tim Haley wrote: > I am sponsoring the following fast-track for myself. This case > introduces additional zpool sub-command options to support pool > recovery. The case is requesting micro/patch binding. Timeout is > 09/16/2009. +1 -Seb From Victor.Latushkin@sun.com Mon Sep 14 13:36:16 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8EKaGs9003643 for ; Mon, 14 Sep 2009 13:36:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8EKaEi3004869; Mon, 14 Sep 2009 13:36:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPZ0000BAKEYL00@brm-avmta-1.central.sun.com>; Mon, 14 Sep 2009 14:36:14 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPZ00FTAAKDYF50@brm-avmta-1.central.sun.com>; Mon, 14 Sep 2009 14:36:14 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8EKaDJ4012720; Mon, 14 Sep 2009 20:36:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPZ00G00AAX4400@fe-emea-10.sun.com>; Mon, 14 Sep 2009 21:36:00 +0100 (BST) Received: from [129.156.248.32] ([unknown] [129.156.248.32]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPZ0082FAJZCK80@fe-emea-10.sun.com>; Mon, 14 Sep 2009 21:36:00 +0100 (BST) Date: Tue, 15 Sep 2009 00:35:59 +0400 From: Victor Latushkin Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <200909100340.n8A3eXmo023660@spidey.local> Sender: Victor.Latushkin@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, zfs-team@sun.com Reply-to: Victor.Latushkin@sun.com Message-id: <4AAEA92F.2010306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 1621 On 10.09.09 07:40, Tim Haley wrote: > I am sponsoring the following fast-track for myself. This case > introduces additional zpool sub-command options to support pool > recovery. The case is requesting micro/patch binding. Timeout is > 09/16/2009. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > zpool recovery support > 1.2. Name of Document Author/Supplier: > Author: Timothy Haley > 1.3 Date of This Document: > 09 September, 2009 > 4. Technical Description > > OVERVIEW: > > Uncooperative or deceptive hardware, combined with power > failures or sudden lack of access to devices, can result in > zpools without redundancy being non-importable. ZFS' > copy-on-write and Merkle tree properties will sometimes allow > us to recover from these problems. Only ad-hoc means currently > exist to take advantage of this recoverability. This proposal > aims to rectify that short-coming. > > PROPOSED SOLUTION: > > This fast-track proposes two new command line flags each for > the 'zpool clear' and 'zpool import' sub-commands. 'zpool clear' is becoming more and more overloaded in meaning. Currently it is used to clear error counters (original use) and recover from faulted slog device or suspended state (though there's no mention of it in the man page). This is confusing users and have been brought up several times (at least) on zfs-discuss. isn't it better to introduce another subcommand 'recover' or something to handle all sorts of recovery? victor From tim.haley@sun.com Mon Sep 14 15:03:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8EM3OI8025806 for ; Mon, 14 Sep 2009 15:03:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8EM3Iet003718; Mon, 14 Sep 2009 23:03:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPZ00A09ELL3W00@brm-avmta-1.central.sun.com>; Mon, 14 Sep 2009 16:03:21 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPZ00FFDELKYTA0@brm-avmta-1.central.sun.com>; Mon, 14 Sep 2009 16:03:20 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8EM3KE2029111; Mon, 14 Sep 2009 22:03:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPZ00C00DZE9100@mail-amer.sun.com>; Mon, 14 Sep 2009 16:03:20 -0600 (MDT) Received: from [172.20.25.27] ([unknown] [172.20.25.27]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPZ000DLEL23T80@mail-amer.sun.com>; Mon, 14 Sep 2009 16:03:03 -0600 (MDT) Date: Mon, 14 Sep 2009 16:03:02 -0600 From: Tim Haley Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <4AAEA92F.2010306@Sun.COM> Sender: Timothy.Haley@sun.com To: Victor.Latushkin@sun.com Cc: PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AAEBD96.6040105@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> <4AAEA92F.2010306@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 2177 Victor Latushkin wrote: > On 10.09.09 07:40, Tim Haley wrote: >> I am sponsoring the following fast-track for myself. This case >> introduces additional zpool sub-command options to support pool >> recovery. The case is requesting micro/patch binding. Timeout is >> 09/16/2009. >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> zpool recovery support >> 1.2. Name of Document Author/Supplier: >> Author: Timothy Haley >> 1.3 Date of This Document: >> 09 September, 2009 >> 4. Technical Description >> >> OVERVIEW: >> >> Uncooperative or deceptive hardware, combined with power >> failures or sudden lack of access to devices, can result in >> zpools without redundancy being non-importable. ZFS' >> copy-on-write and Merkle tree properties will sometimes allow >> us to recover from these problems. Only ad-hoc means currently >> exist to take advantage of this recoverability. This proposal >> aims to rectify that short-coming. >> >> PROPOSED SOLUTION: >> >> This fast-track proposes two new command line flags each for >> the 'zpool clear' and 'zpool import' sub-commands. > > 'zpool clear' is becoming more and more overloaded in meaning. Currently > it is used to clear error counters (original use) and recover from > faulted slog device or suspended state (though there's no mention of it > in the man page). This is confusing users and have been brought up > several times (at least) on zfs-discuss. > > isn't it better to introduce another subcommand 'recover' or something > to handle all sorts of recovery? > "Better" is subjective. For the limited recovery we are going to support at the moment, the single flag to clear or import is probably sufficient. The confusion of what to run to recover should hopefully be abated by failed imports and 'zpool status' directing the administrator exactly what to run to perform a recovery. Having the flag now does not preclude us from adding a recover subcommand in the future for more advanced recovery. -tim From Darren.Reed@sun.com Mon Sep 14 18:19:11 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8F1JAIH013612 for ; Mon, 14 Sep 2009 18:19:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8F1J8A3028102; Mon, 14 Sep 2009 18:19:10 -0700 (PDT) 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 <0KPZ0090FNNXT800@nwk-avmta-2.sfbay.sun.com>; Mon, 14 Sep 2009 18:19:09 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPZ00FNHNNWB8D0@nwk-avmta-2.sfbay.sun.com>; Mon, 14 Sep 2009 18:19:09 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8F1J7Er025973; Tue, 15 Sep 2009 01:19:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPZ00100NH29000@fe-emea-09.sun.com>; Tue, 15 Sep 2009 02:18:47 +0100 (BST) Received: from [129.146.106.55] ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPZ00171NN2NNA0@fe-emea-09.sun.com>; Tue, 15 Sep 2009 02:18:40 +0100 (BST) Date: Mon, 14 Sep 2009 18:19:45 -0700 From: Darren Reed Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <4AAEBD96.6040105@sun.com> Sender: Darren.Reed@sun.com To: Tim Haley Cc: Victor.Latushkin@sun.com, PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AAEEBB1.4020205@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> <4AAEA92F.2010306@Sun.COM> <4AAEBD96.6040105@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090608) Status: RO Content-Length: 3492 On 14/09/09 03:03 PM, Tim Haley wrote: > Victor Latushkin wrote: >> On 10.09.09 07:40, Tim Haley wrote: >>> I am sponsoring the following fast-track for myself. This case >>> introduces additional zpool sub-command options to support pool >>> recovery. The case is requesting micro/patch binding. Timeout is >>> 09/16/2009. >>> >>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>> This information is Copyright 2009 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> zpool recovery support >>> 1.2. Name of Document Author/Supplier: >>> Author: Timothy Haley >>> 1.3 Date of This Document: >>> 09 September, 2009 >>> 4. Technical Description >>> >>> OVERVIEW: >>> >>> Uncooperative or deceptive hardware, combined with power >>> failures or sudden lack of access to devices, can result in >>> zpools without redundancy being non-importable. ZFS' >>> copy-on-write and Merkle tree properties will sometimes allow >>> us to recover from these problems. Only ad-hoc means currently >>> exist to take advantage of this recoverability. This proposal >>> aims to rectify that short-coming. >>> >>> PROPOSED SOLUTION: >>> >>> This fast-track proposes two new command line flags each for >>> the 'zpool clear' and 'zpool import' sub-commands. >> >> 'zpool clear' is becoming more and more overloaded in meaning. >> Currently it is used to clear error counters (original use) and >> recover from faulted slog device or suspended state (though there's >> no mention of it in the man page). This is confusing users and have >> been brought up several times (at least) on zfs-discuss. >> >> isn't it better to introduce another subcommand 'recover' or >> something to handle all sorts of recovery? >> > "Better" is subjective. For the limited recovery we are going to > support at the moment, the single flag to clear or import is probably > sufficient. The confusion of what to run to recover should hopefully > be abated by failed imports and 'zpool status' directing the > administrator exactly what to run to perform a recovery. > > Having the flag now does not preclude us from adding a recover > subcommand in the future for more advanced recovery. If this is a limited recover mechanism then why not make this a variant of the recover subcommand, rather than clear? That seems more obvious to me, in terms of usability. However, it should be noted that "zpool clear" does fit the "svcadm clear" operational model. In light of that, if z "zpool recover" is added at some point in the future, would a "zpool clear" automatically do whatever extended recovery was possible to enable the pool to be mounted? Given that "zpool clear" is a recovery operation (of sorts) and that you're hinting at there being thought about a more advanced recovery option, I think it would be beneficial to understand more about what the project team intends to do that requires us to have recovery performed by two different subcommands. For example, how will I know when it is appropriate to use "zpool clear" vs "zpool recover"? Is user confusion likely from having two subcommands that do similar but different things, depending on the circumstances at hand? I appreciate that you haven't formally presented us with a case that mentions "zpool recover", but your email here hints that there is more to follow and that might help us put this case in better perspective. Darren From tim.haley@sun.com Tue Sep 15 09:35:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8FGZmag024795 for ; Tue, 15 Sep 2009 09:35:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8FGZWR1027869; Tue, 15 Sep 2009 17:35:47 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ000B0DU3NQ100@brm-avmta-1.central.sun.com>; Tue, 15 Sep 2009 10:35:47 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ0002HMU3LC290@brm-avmta-1.central.sun.com>; Tue, 15 Sep 2009 10:35:45 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8FGZjFR025753; Tue, 15 Sep 2009 16:35:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ000300SBIRX00@mail-amer.sun.com>; Tue, 15 Sep 2009 10:35:45 -0600 (MDT) Received: from [172.20.25.27] ([unknown] [172.20.25.27]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ00039AU3DWZF0@mail-amer.sun.com>; Tue, 15 Sep 2009 10:35:38 -0600 (MDT) Date: Tue, 15 Sep 2009 10:35:37 -0600 From: Tim Haley Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <4AAEEBB1.4020205@Sun.COM> Sender: Timothy.Haley@sun.com To: Darren Reed Cc: Victor.Latushkin@sun.com, PSARC-ext@sun.com, zfs-team@sun.com Message-id: <4AAFC259.90305@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> <4AAEA92F.2010306@Sun.COM> <4AAEBD96.6040105@sun.com> <4AAEEBB1.4020205@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 3858 Darren Reed wrote: > On 14/09/09 03:03 PM, Tim Haley wrote: >> Victor Latushkin wrote: >>> On 10.09.09 07:40, Tim Haley wrote: >>>> I am sponsoring the following fast-track for myself. This case >>>> introduces additional zpool sub-command options to support pool >>>> recovery. The case is requesting micro/patch binding. Timeout is >>>> 09/16/2009. >>>> >>>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>>> This information is Copyright 2009 Sun Microsystems >>>> 1. Introduction >>>> 1.1. Project/Component Working Name: >>>> zpool recovery support >>>> 1.2. Name of Document Author/Supplier: >>>> Author: Timothy Haley >>>> 1.3 Date of This Document: >>>> 09 September, 2009 >>>> 4. Technical Description >>>> >>>> OVERVIEW: >>>> >>>> Uncooperative or deceptive hardware, combined with power >>>> failures or sudden lack of access to devices, can result in >>>> zpools without redundancy being non-importable. ZFS' >>>> copy-on-write and Merkle tree properties will sometimes allow >>>> us to recover from these problems. Only ad-hoc means currently >>>> exist to take advantage of this recoverability. This proposal >>>> aims to rectify that short-coming. >>>> >>>> PROPOSED SOLUTION: >>>> >>>> This fast-track proposes two new command line flags each for >>>> the 'zpool clear' and 'zpool import' sub-commands. >>> >>> 'zpool clear' is becoming more and more overloaded in meaning. >>> Currently it is used to clear error counters (original use) and >>> recover from faulted slog device or suspended state (though there's >>> no mention of it in the man page). This is confusing users and have >>> been brought up several times (at least) on zfs-discuss. >>> >>> isn't it better to introduce another subcommand 'recover' or >>> something to handle all sorts of recovery? >>> >> "Better" is subjective. For the limited recovery we are going to >> support at the moment, the single flag to clear or import is probably >> sufficient. The confusion of what to run to recover should hopefully >> be abated by failed imports and 'zpool status' directing the >> administrator exactly what to run to perform a recovery. >> >> Having the flag now does not preclude us from adding a recover >> subcommand in the future for more advanced recovery. > > If this is a limited recover mechanism then why not make this a variant > of the recover subcommand, rather than clear? > > That seems more obvious to me, in terms of usability. > > However, it should be noted that "zpool clear" does fit the "svcadm > clear" operational model. > > In light of that, if z "zpool recover" is added at some point in the > future, would a "zpool clear" automatically do whatever extended > recovery was possible to enable the pool to be mounted? > > Given that "zpool clear" is a recovery operation (of sorts) and that > you're hinting at there being thought about a more advanced recovery > option, I think it would be beneficial to understand more about what the > project team intends to do that requires us to have recovery performed > by two different subcommands. > You've read a lot more into my statement than I ever meant to imply. I only meant that if we thought up something exotic in the longer term, we could still consider a new sub-command. I doubt it would be necessary, though. -tim > For example, how will I know when it is appropriate to use "zpool clear" > vs "zpool recover"? > Is user confusion likely from having two subcommands that do similar but > different things, depending on the circumstances at hand? > > I appreciate that you haven't formally presented us with a case that > mentions "zpool recover", but your email here hints that there is more > to follow and that might help us put this case in better perspective. > > Darren > From tim.haley@sun.com Wed Sep 16 10:12:18 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8GHCGGB006698 for ; Wed, 16 Sep 2009 10:12:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8GHCA7C000660; Thu, 17 Sep 2009 01:12:15 +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 <0KQ200903QGEDN00@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 10:12:14 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ2001D0QGEZ2A0@nwk-avmta-2.sfbay.sun.com>; Wed, 16 Sep 2009 10:12:14 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8GHCDSl021192; Wed, 16 Sep 2009 17:12:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ200300PQRWV00@mail-amer.sun.com>; Wed, 16 Sep 2009 11:12:13 -0600 (MDT) Received: from [172.20.25.27] ([unknown] [172.20.25.27]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ20066ZQGA5I60@mail-amer.sun.com>; Wed, 16 Sep 2009 11:12:11 -0600 (MDT) Date: Wed, 16 Sep 2009 11:12:10 -0600 From: Tim Haley Subject: Re: zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009] In-reply-to: <200909100340.n8A3eXmo023660@spidey.local> Sender: Timothy.Haley@sun.com To: PSARC-ext@sun.com Cc: zfs-team@sun.com Message-id: <4AB11C6A.8060607@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909100340.n8A3eXmo023660@spidey.local> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 56 This case was approved in today's PSARC meeting. -tim