Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 May 2015 16:35:46 +0300
From:      Slawa Olhovchenkov <slw@zxy.spb.ru>
To:        Ronald Klop <ronald-lists@klop.ws>
Cc:        Steven Hartland <killing@multiplay.co.uk>, freebsd-stable@freebsd.org
Subject:   Re: zfs, cam sticking on failed disk
Message-ID:  <20150507133546.GA62239@zxy.spb.ru>
In-Reply-To: <op.xx9o261skndu52@ronaldradial.radialsg.local>
References:  <554B53E8.4000508@multiplay.co.uk> <20150507120508.GX62239@zxy.spb.ru> <554B5BF9.8020709@multiplay.co.uk> <20150507124416.GD1394@zxy.spb.ru> <554B5EB0.1080208@multiplay.co.uk> <20150507125129.GY62239@zxy.spb.ru> <554B6307.9020309@multiplay.co.uk> <20150507131007.GZ62239@zxy.spb.ru> <554B676E.8020500@multiplay.co.uk> <op.xx9o261skndu52@ronaldradial.radialsg.local>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150507133546.GA62239>