George Wilson wrote:
> 
> 
> Darren J Moffat wrote:
>> George Wilson wrote:
>>>
>>> Darren J Moffat wrote:
>>>> Mark Maybee wrote:
>>>>> Darren J Moffat wrote:
>>>>>> For an encrypted dataset it is possible that by the time we arrive 
>>>>>> in zio_write() [ zio_write_encrypt() ] that when we lookup which 
>>>>>> key is needed to encrypted this data that key isn't available to us.
>>>>>>
>>>>>> Is there some value of zio->io_error I can set that will not 
>>>>>> result in a panic ? but will put the write in to some state where 
>>>>>> we can try again later - I guess not just this write but maybe the 
>>>>>> whole transaction group ?
>>>>>>
>>>>> No, we have no ability to do this.  With George's fix for 6565042, we
>>>>> will introduce the ability to "hang" the pool on an IO failure... this
>>>>> may give you what you want.
>>>> It might well do, but will it allow "unhanging" later ?  I couldn't 
>>>> tell much from that bug unfortunately.
>>>>
>>>
>>> Once the error is corrected you will be able to resume the IOs.
>>
>> Great.  I'm thinking I might in the missing encryption key case even 
>> want to fire off a sysevent so that someone knows the key is missing. 
>> Does that sound reasonable ?
>>
> 
> BTW, you will need to ensure that if you set the io_error in 
> zio_encrypt_write() that it does not get overwritten in a later stage. 
> Would you send the sysevent in zio_write_encrypt() or wait till zio_done()?

I'd probably sent it in zio_crypt_key_lookup() which zio_write_encrypt() 
and zio_read_decrypt() both call.

Any opinion on what a suitable value for io_error would be ?  EIO feels 
wrong, EPERM is maybe closer but not quite correct.

> Keep in mind that the user may decide to set the failure mode to one of 
> three options:
> 
> 1). wait - stop all IOs and block until the error is cleared
> 2). continue - new IOs will return EIO but in-flight IOs will block 
> until the error is cleared
> 3). panic - same behavior, nicer message.

This sounds like a new pool level property, would that be the correct 
interpretation ?

-- 
Darren J Moffat

Reply via email to