On 05/07/15 14:32, Steven Hartland wrote: > > > On 07/05/2015 14:29, 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 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 ;-)
zpool offline -t zroot da19
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
