iSCSI disconnects dilema

[Oliver Fromme]

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