zfs, cam sticking on failed disk

[Ronald Klop]

On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland  
<killing at multiplay.co.uk> wrote:

>
>
> 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.
>


Maybe I'm talking BS here, but does 'camcontrol eject' do something on a  
disk?

Ronald.