Date: Tue, 9 Jan 2007 12:02:31 -0500 From: John Nielsen <lists@jnielsen.net> To: freebsd-hackers@freebsd.org Cc: freebsd-scsi@freebsd.org, Dan Nelson <dnelson@allantgroup.com> Subject: Re: iSCSI disconnects dilema Message-ID: <200701091202.32226.lists@jnielsen.net> In-Reply-To: <E1H4B4I-0001eX-UC@cs1.cs.huji.ac.il> References: <E1H4B4I-0001eX-UC@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
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@allantgroup.com> To: DAve <dave.list@pixelhammer.com> Cc: Free BSD Questions list <freebsd-questions@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701091202.32226.lists>