From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 8 02:40:35 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E24F1065670 for ; Thu, 8 Jan 2009 02:40:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC6A8FC1B for ; Thu, 8 Jan 2009 02:40:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 2D36B17D7E; Thu, 8 Jan 2009 13:40:35 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [10.1.50.60] (ppp121-44-0-132.lns10.syd7.internode.on.net [121.44.0.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 0B3F2172CC; Thu, 8 Jan 2009 13:40:31 +1100 (EST) Message-ID: <49656791.1000809@modulus.org> Date: Thu, 08 Jan 2009 13:40:17 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.14 (X11/20080523) MIME-Version: 1.0 To: Angelo , freebsd-scsi@freebsd.org References: <6c1e076a0901070247l7c006efajda8fddee84c337a@mail.gmail.com> In-Reply-To: <6c1e076a0901070247l7c006efajda8fddee84c337a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: iscsi client hangs performing I/O on a dead target X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 02:40:35 -0000 > I was expecting that a failure on one of the disks (network down, target > machine down) would be eventually detected and the raid turned to degraded > but still usable. > What happens now to me is that the whole raid device gets unusable for all > the time the target is down. If you're using gmirror, you might want to experiment with this setting: kern.geom.mirror.timeout Set it to something reasonably low like 10 seconds, and it will ignore an iSCSI device that is not responding more rapidly.