Date: Tue, 9 Jan 2007 10:09:32 -0800 From: "Jeff Mohler" <speedtoys.racing@gmail.com> To: "Dan Nelson" <dnelson@allantgroup.com>, DAve <dave.list@pixelhammer.com>, "Free BSD Questions list" <freebsd-questions@freebsd.org> Subject: Re: iSCSI Message-ID: <a969fbd10701091009i2f41789ek9657cedf2eef3df2@mail.gmail.com> In-Reply-To: <20070109163557.GH41724@dan.emsphone.com> References: <45A2A0E6.7090202@pixelhammer.com> <200701081508.20632.lists@jnielsen.net> <45A399BD.9080707@pixelhammer.com> <20070109163557.GH41724@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That only works if the target comes up within the 2min window that SCSI allows for. It won't wait forever. On 1/9/07, Dan Nelson <dnelson@allantgroup.com> wrote: > 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. > > -- > Dan Nelson > dnelson@allantgroup.com > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a969fbd10701091009i2f41789ek9657cedf2eef3df2>