freebsd stable - May 2015 - zfs, cam sticking on failed disk

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'?

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.

Hence if you pull the disk things should continue as normal, with the 
failed device being marked as such.

     Regards
     Steve