From owner-freebsd-stable@FreeBSD.ORG Thu May 7 13:32:40 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 D5A412C7 for ; Thu, 7 May 2015 13:32:40 +0000 (UTC) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E7CC166B for ; Thu, 7 May 2015 13:32:40 +0000 (UTC) Received: by wgyo15 with SMTP id o15so43719558wgy.2 for ; Thu, 07 May 2015 06:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZHcqNoqge73HSIwXbfy8Zt8bpk5O3XbuFyEz2qtEdiQ=; b=J0xPMlUsumLnbtZQTCUozH/sdORjzGQbdHQ6ybn4yI9wEjfNkMJ6cjf+ZCx4FpvAMZ kQvOZ/9+uH0iIiBkJYPFFZhYAqbq9PhmMptmwjDAY6VNF4zQF0aOMysI65JNVkXoKx6S 3eVNCse7Ah7iyr7NEqYmKK3RuY+I6AsVyQ87JVNY08frmB7YewJjExANxpPfn833eE5h reyc3X7Rb2AGRh13+aZyWnNIu/tuHIq9gi3fEItwQ4ZwLgliLPDAkToh9vCs4T1pb1eY 7YF7ECZanubA/aKPkAmq/iNiyjBdwjyeY0fx4I5L0OYqBGl35ZK3FxNvlNcdyQt/1tjT k0Uw== X-Gm-Message-State: ALoCoQmesT+GU7sU4W4iUg9LMCo/7WjIVUuonsYYV4tN+Iorewx7TZX+7bvbb/iUgCw7r6QMdwPR X-Received: by 10.194.123.67 with SMTP id ly3mr7633396wjb.105.1431005558954; Thu, 07 May 2015 06:32:38 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id mv11sm7465099wic.23.2015.05.07.06.32.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 06:32:38 -0700 (PDT) Message-ID: <554B696F.6020902@multiplay.co.uk> Date: Thu, 07 May 2015 14:32:31 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ronald Klop , Slawa Olhovchenkov 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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:32:41 -0000 On 07/05/2015 14:29, 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 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