From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 9 17:05:19 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2369516A494; Tue, 9 Jan 2007 17:05:19 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 04A7B13C4A6; Tue, 9 Jan 2007 17:05:18 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from localhost (jn@ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id l09H574o019218; Tue, 9 Jan 2007 09:05:07 -0800 (PST) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-hackers@freebsd.org Date: Tue, 9 Jan 2007 12:02:31 -0500 User-Agent: KMail/1.9.5 References: In-Reply-To: X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701091202.32226.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, Dan Nelson Subject: Re: iSCSI disconnects dilema 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: Tue, 09 Jan 2007 17:05:19 -0000 Forwarding a relevant comment from a parallel discussion on -questions. ---------- Forwarded Message ---------- Subject: Re: iSCSI Date: Tuesday 09 January 2007 11:35 From: Dan Nelson To: DAve Cc: Free BSD Questions list In the last episode (Jan 09), DAve said: > The developers response, for those who are interested. > > hi Dave, > the initiator for iSCSI will hit stable/current real soon now. > that was the good news, now for the down side: > what was missing all along was recovery from network disconnects, so > while I think I have it almost worked out, I've come across a major > flow in the iscsi design: > when the targets crashes, and comes back, there is no way > to tell the client to run an fsck. This is not a problem if the > client is mounting the iscsi partition read only. > > danny Why should the client need to do an fsck? From its point of view it should just look like the target had the iSCSI equivalent of a bus reset. It should resend any queued requests and continue. On Tuesday 09 January 2007 02:06, Danny Braniss wrote: > Hi, > While I think I have almost solved the problem of network disconnects, > It downed on me a major problem: > When a 'local' disk crashes, the kernel will probably hang/panic/crash. > if i don't try to recover, then there is no change in the above scenario. > if i try to recover, then the client does not know that it should > umount/fsck/mount. > While all this seems familiar, removing a floppy/disk-on-key while it's > mounted, we could always say "you shouldn't have done that!", with > a network connection, it can happen very often - rebooting the target, a > network hickup, etc.