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()? 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. Thanks, George
