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
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.
On 07/05/2015 14:29, Ronald Klop wrote:> 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?I wouldn't have thought so, I would expect that to only have an effect on removal media such as CDROM drives, but no harm in trying ;-) Regards Steve
On Thu, May 07, 2015 at 03:29:20PM +0200, Ronald Klop wrote:> 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?I am don't try 'camcontrol eject' but 'camcontrol identify' already stalled. Need control on adapter layer.