iSCSI disconnects dilema

[John Nielsen]

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 <dnelson at allantgroup.com>
To: DAve <dave.list at pixelhammer.com>
Cc: Free BSD Questions list <freebsd-questions at freebsd.org>

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.