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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
