From owner-freebsd-stable@FreeBSD.ORG Thu May 7 13:44:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FC3B60A for ; Thu, 7 May 2015 13:44:57 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EBFF179B for ; Thu, 7 May 2015 13:44:57 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YqLrd-0004F8-DD; Thu, 07 May 2015 15:29:27 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Slawa Olhovchenkov" , "Steven Hartland" Cc: freebsd-stable@freebsd.org Subject: Re: zfs, cam sticking on failed disk References: <20150507095048.GC1394@zxy.spb.ru> <554B40B6.6060902@multiplay.co.uk> <20150507104655.GT62239@zxy.spb.ru> <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> Date: Thu, 07 May 2015 15:29:20 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <554B676E.8020500@multiplay.co.uk> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50, URIBL_BLOCKED autolearn=disabled version=3.3.2 X-Scan-Signature: e462de357cb394d64966911c06262bc8 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:44:57 -0000 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? Ronald.