On Thu, May 07, 2015 at 03:29:20PM +0200, Ronald Klop wrote: > On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland > <kill...@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?
I am don't try 'camcontrol eject' but 'camcontrol identify' already stalled. Need control on adapter layer. _______________________________________________ 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"
