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
