zfs, cam sticking on failed disk

Steven Hartland killing at multiplay.co.uk
Thu May 7 13:05:27 UTC 2015



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


More information about the freebsd-stable mailing list