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 >
