From owner-freebsd-stable@FreeBSD.ORG  Thu May  7 12:51:32 2015
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 579958F8
 for <freebsd-stable@freebsd.org>; Thu,  7 May 2015 12:51:32 +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 0FBC511A9
 for <freebsd-stable@freebsd.org>; Thu,  7 May 2015 12:51:32 +0000 (UTC)
Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1YqLH0-0002nZ-1P; Thu, 07 May 2015 15:51:30 +0300
Date: Thu, 7 May 2015 15:51:29 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: Steven Hartland <killing@multiplay.co.uk>
Cc: freebsd-stable@freebsd.org
Subject: Re: zfs, cam sticking on failed disk
Message-ID: <20150507125129.GY62239@zxy.spb.ru>
References: <20150507080749.GB1394@zxy.spb.ru>
 <554B2547.1090307@multiplay.co.uk>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554B5EB0.1080208@multiplay.co.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
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 <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 12:51:32 -0000

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'?