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



Reply via email to