From owner-freebsd-scsi@FreeBSD.ORG Wed Jan 7 13:27:59 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 A6AC7106566B for ; Wed, 7 Jan 2009 13:27:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9118FC14 for ; Wed, 7 Jan 2009 13:27:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LKYRx-0000na-VV; Wed, 07 Jan 2009 15:27:58 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Angelo In-reply-to: <6c1e076a0901070247l7c006efajda8fddee84c337a@mail.gmail.com> References: <6c1e076a0901070247l7c006efajda8fddee84c337a@mail.gmail.com> Comments: In-reply-to Angelo message dated "Wed, 07 Jan 2009 11:47:17 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jan 2009 15:27:57 +0200 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org 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: Wed, 07 Jan 2009 13:28:00 -0000 > ------=_Part_16620_23870833.1231325237102 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > On Wed, Jan 7, 2009 at 10:33 AM, Danny Braniss wrote: > > > > Hi, > > > > > > I'm experimenting on iscsi; both the target and the initiator are vmware > > > virtual machines and are running 7.0-RELEASE. > > > So far everything works fine except that the client hangs forever (state > > is > > > PHYSWR) if it is accessing (dd if=/dev/zero of=/dev/da0) the device while > > it > > > "dies" (shutdown of the target machine). > > > > > what happens when you bring back the target? > > > > > Is this the expected behaviour? > > > > > yes. > > but maybe it can be 'fixed', I'm concidering adding some kind of timeout > > flag/option. > > > > > I would like to be able to configure a timeout so the command that is > > trying > > > to access the unavailable device fails and I can handle the problem but I > > > can't find anything in iscontrol man pages. > > > > > > Thanks, > > > Angelo > > > _______________________________________________ > > > freebsd-scsi@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > > > > > > Hi Danny, > > > thanks for your reply. > > when the target comes back it is reconnected properly by the initiator. > > The usage of iscsi I had in mind was an initiator connecting to two targets > and using the two devices as parts of a raid 1 array. > 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. > > As I said before I am just experimenting. I don't know how other > implementations of iscsi initiator work and maybe my idea is just insane :) > I don't know either, the RFC does not mention this case - or maybe I missed it :-) But others have raised the issue, and so it got me thinking, but freebsd likes to panic if a disc goes away, so don't hold your breath for a solution soon. danny > Thanks, > Angelo