On Jan 30, 2007, at 10:34 PM, Eric Enright wrote:
On 1/30/07, Rick McNeal <[EMAIL PROTECTED]> wrote:
Yes, to make a long story short I've spotted the bug in the daemon.
It'll take a couple of days to make the fix only because I've got a
couple of things on my plate which need to be completed first.
Any chance you could give a (brief) outline of the bug? I started
digging into the iscsitgt code a little tonight but a quick pointer
would help things along.
The problem is that after no activity on the connection for 30
seconds I want to send a ping. At some point in the future the target
will close the connection and free the resources if we fail to
receive a reply. Now, it's the receive thread that determines that
there's no activity and wants to send a ping, but it can't send
messages[1]. So the receiver thread builds a NOP-In header and places
it on the writer threads queue. The writer thread takes the message
off, calls a generic output routine which fills in a few fields and
sends the message. This generic routine is used in two other place
for sending out responses. The problem is that I've got one routine
which is sending out responses and a request which have different
runs as to what's updated. The quick fix is to remove the call to
queue_noop_in() in iscsi_conn.c. My fix will be to create a different
routine which fills in the request header, mainly it will not update
the status sequence number.
[1] The receiver can't send messages for two reasons. (a) it could
interlace data with the writer thread's data causing all sorts of
problems. (b) there are limits to the amount of data the kernel will
hold in a socket. If that limit is reached anyone trying to write to
the socket will block. Therefore, the receiver, which drains the
socket, could block because it's trying to perform a write op.
Regards,
Eric
On Jan 30, 2007, at 8:56 PM, Wally Hunt wrote:
> "Whenever the NOP-In is sent as a "ping" to an initiator (not as a
> response to a NOP-Out), the StatSN field will contain the next
> StatSN. However, StatSN for this connection is not advanced.".
> That dosen't seem to be occuring in this situation.
>
> w
>
>
> This message posted from opensolaris.org
> _______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate
attempt on your part to deprive me of happiness, the pursuit of which
is my unalienable right according to the Declaration of
Independence. I therefore assert my patriotic prerogative not to
know this material. I'll be out on the playground." -- Calvin
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
--
Eric Enright
----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate
attempt on your part to deprive me of happiness, the pursuit of which
is my unalienable right according to the Declaration of
Independence. I therefore assert my patriotic prerogative not to
know this material. I'll be out on the playground." -- Calvin
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
