From owner-freebsd-stable@FreeBSD.ORG Thu May 7 13:35:49 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F06593D3 for ; Thu, 7 May 2015 13:35:49 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8A331689 for ; Thu, 7 May 2015 13:35:49 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YqLxr-0003Ya-0W; Thu, 07 May 2015 16:35:47 +0300 Date: Thu, 7 May 2015 16:35:46 +0300 From: Slawa Olhovchenkov To: Ronald Klop Cc: Steven Hartland , freebsd-stable@freebsd.org Subject: Re: zfs, cam sticking on failed disk Message-ID: <20150507133546.GA62239@zxy.spb.ru> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:35:50 -0000 On Thu, May 07, 2015 at 03:29:20PM +0200, Ronald Klop wrote: > On Thu, 07 May 2015 15:23:58 +0200, Steven Hartland > 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.