Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jan 2007 21:31:04 +0200
From:      Danny Braniss <danny@cs.huji.ac.il>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        freebsd-scsi@FreeBSD.org, freebsd-hackers@freebsd.org
Subject:   Re: iSCSI disconnects dilema 
Message-ID:  <E1H5S7E-000BS0-RR@cs1.cs.huji.ac.il>
In-Reply-To: Your message of Fri, 12 Jan 2007 20:02:49 %2B0100 .

next in thread | raw e-mail | index | archive | help
> 
> --s/l3CgOIzMHHjg/5
> Content-Type: text/plain; charset=iso-8859-2
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Jan 09, 2007 at 09:06:46AM +0200, 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.
> >=20
> > So, any ideas?
> 
> In my opinion it should be done this way:
> 
> You have a queue of I/O requests. You send the to the other end and wait
> for confirmation. Until confirmation is received, you keep the requests
> queued. If the other end dies, you try to reconnect (until some timeout
> expires, the processes which send those requests will just wait), if you
> reconnect successfully, you resend not-confirmed requests, if you won't
> be able to reconnect, you just pass the errors up.
> 
> This is what I did in ggate and it seems to work.

That is basically what i'm doing - unacked request get requed.
the problem I fear (and maybe I'm paranoid :-):

assume the following scenario, the client(initiator) sends a write command,
the target acks it, then it crashes, if the write was never completed,
the initiator goes on as nothing ever happened. 

danny





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1H5S7E-000BS0-RR>