On 07/05/2015 14:10, Slawa Olhovchenkov wrote:> On Thu, May 07, 2015 at 02:05:11PM +0100, Steven Hartland wrote:
>
>>
>> On 07/05/2015 13:51, Slawa Olhovchenkov wrote:
>>> On Thu, May 07, 2015 at 01:46:40PM +0100, Steven Hartland wrote:
>>>
>>>>>> Yes in theory new requests should go to the other vdev,
but there could
>>>>>> be some dependency issues preventing that such as a
syncing TXG.
>>>>> Currenly this pool must not have write activity (from
application).
>>>>> What about go to the other (mirror) device in the same
vdev?
>>>>> Same dependency?
>>>> Yes, if there's an outstanding TXG, then I believe all IO
will stall.
>>> Where this TXG released? When all devices in all vdevs report
>>> 'completed'? When at the least one device in all vdevs
report
>>> 'completed'? When at the least one device in at least one
vdev report
>>> 'completed'?
>> When all devices have report completed or failed.
> Thanks for explained.
>
>> Hence if you pull the disk things should continue as normal, with the
>> failed device being marked as such.
> I am have trouble to phisical access.
> May be someone can be suggest software method to forced detach device
> from system.
In 11 that should be possible with devctl, but under 10 I'm not aware of
anything that wouldn't involve some custom kernel level code I'm afraid.
Regards
Steve