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 <[EMAIL PROTECTED]> To: DAve <[EMAIL PROTECTED]> Cc: Free BSD Questions list <[email protected]> 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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
