From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 9 16:16:55 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B568916A416 for ; Tue, 9 Jan 2007 16:16:55 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 28F6F13C45E for ; Tue, 9 Jan 2007 16:16:54 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uvqlwx@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l09GGUZT020582; Tue, 9 Jan 2007 17:16:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l09GGTJu020581; Tue, 9 Jan 2007 17:16:29 +0100 (CET) (envelope-from olli) Date: Tue, 9 Jan 2007 17:16:29 +0100 (CET) Message-Id: <200701091616.l09GGTJu020581@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, danny@cs.huji.ac.il In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 09 Jan 2007 17:16:35 +0100 (CET) Cc: Subject: Re: iSCSI disconnects dilema X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, danny@cs.huji.ac.il List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 16:16:55 -0000 Danny Braniss wrote: > 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. The IEEE1394 code (firewire) contains a hack so you can remove a _mounted_ drive (yes, pull the plug!) and later reconnect it and continue to use the filesystem. I think processes that try to access the file system during the drive being unavailable are blocked ("D" state a.k.a. "diskwait"). The purpose of that feature is that you can change the topology (e.g. remove a device that's not at the end of the bus) without having to unmount all other devices. Well, it's just a hack, and I don't know if something similar is applicable to the iSCSI situation. But I thought it wouldn't hurt to mention it anyhow. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal