|
>>The way all the application
handle cases when the start of some SCSI
>>command has to follow the
end of a previous set of operations is to just
>>wait for the end of
the operations before issuing the "dependent commands".
This is not to object to your observation but wouldn't ordered
tags were used for the above purpose?
Eddy
----- Original Message -----
Sent: Saturday, January 06, 2007 9:31
AM
Subject: Fw: Response Fence
Flag
----- Forwarded
by Julian Satran/Haifa/IBM on 06/01/07 09:27 -----
Mallikarjun & All,
As I pointed out in a private discussion
with you I never considered in
dept the response-fence (beyond what is
needed for TM).
It is a serious issue for any "transaction type" operations
to storage -
but the last interface that had all the pieces correctly
aligned was the
360 channel.
SCSI had taken (traditionally) the
positions that sequencing and
barriers are rarely needed and when needed
applications should provide them.
And that is exactly what all of the
relevant applications do (all
transaction monitors, databases
etc.).
The way all the application handle cases when the start of some
SCSI
command has to follow the end of a previous set of operations is to
just
wait for the end of the operations before issuing the "dependent
commands".
Is this solution optimal? As you probably observed already
this solution
implies that all the queues in the "stack" (at initiator,
transport and
target) get empty before the dependent commands can be
issued and that
is bad for performance.
Can fencing (bad name BTW
because it is in widespread use for defect
isolation) improve this? Yes
(by keeping the pipes full!) provided it is
associated with rigorous
exception handling and the later is a SCSI
issue (exceptions will require
emptying the queues). With most
applications being distributed I doubt
also that fencing for a single
I_T nexus is interesting and coordinating
fencing and exception handling
over several I_Ts is a complex
exercise.
And as transport alone brings no value to the whole issue -
why should
we go through the exercise of defining a solution before
SCSI has
defined one and we are confident that it is good enough and has
value?
Again I agree that we a mechanism for TM but a good enough
mechanism for
TM is already in and it gets now even better even without
resorting to a
generalized fencing/barrier
support.
Regards,
Julo
Mallikarjun
C. wrote:
> Trying again after bouncing (>50KB), tail is now
clipped....
>
> ----- Forwarded Message ----
> From:
Mallikarjun C. <cb_mallikarjun@xxxxxxxxx>
> To:
ips@xxxxxxxx
> Sent: Friday, January 5, 2007 2:40:56 PM
> Subject:
Re: Response Fence Flag
>
> Hi John,
>
>
As you correctly point out, there are two distinct but related
> topics
here.
>
> (1) proper response ordering across participating
connections in a
> multi-connection session, for a handful of task/TMF
responses
> (2) proper way to terminate and signal tasks when actions on
one
> session can impact multiple initiators
>
> (1)
is all about response fence, it is covered separately in section
> 3.3
of IG draft. That's what this email thread started off with.
>
> (2) covers cases that IG had called as as "multi-task abort"
cases
> that typically have a shared task set across sessions, or are
the
> result of a Logical Unit Reset TMF. Section 4.1 of IG
adresses (2).
>
> So how are (1) and (2) related?
>
> - Some cases covered under (2) overlap with (1), but some cases
in (2)
> are for single connection sessions. E.g. LU Reset on a
single
> connection session impacting several 3rd party
sessions
>
> - Some cases under (1) overlap with (2), but
some cases in (1) have
> nothing to do with other sessions. E.g.
establishment of ACA on a
> non-shared task set
>
>
- Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
>
(1)) whenever multi-connection sessions are involved in multi-task
>
abort situations.
>
> I hope that clarifies it. Feel
free to ask if that is not clear. The
> net is that the response
fence is the underpinning notion to describe
> the correct iSCSI
behavior in a few cases and some of those cases are
> about task
terminations across third-party sessions.
>
>
Mallikarjun
>
>
>
>
> -----
Original Message ----
> From: John Hufferd
<jhufferd@xxxxxxxxxxx>
> To: Mallikarjun C.
<cb_mallikarjun@xxxxxxxxx>; ips@xxxxxxxx
> Sent: Friday, January
5, 2007 1:01:06 PM
> Subject: RE: Response Fence
Flag
>
> Mallikarjun,
>
> I must admit, that I have
been a bit confused with the direction of
> the conversation
here.
>
>
>
> Therefore, I went back and
reviewed the charts from Dallas . And as I
> remembered, the
initial focus was to address the issue of Multiple
> Connections per
Session (MC/S) (as stated on chart 4 ? ?Non-issue for
>
single-connection iSCSI sessions?). So I think I have missed the step
> where we have morphed the discussion into one dealing with multiple
> sessions. (I am not sure how that happened, or if I miss-read
the
> charts from Dallas , or have not followed the discussion
adequately.)
>
>
>
> If we are attempting to
define two different issues, one with MC/S and
> one with Multiple
Session from different Initiators, I think it would
> be useful to
break down the conversation into Topic A ? MC/S and Topic
> B Multiple
Sessions. It is possible that one solution will addresses
> both,
but I for one think I am hearing arguments that might be
> appropriate
for Topic B, while I am thinking about its applicability
> to Topic
A.
>
>
>
> Perhaps, you could address the issue
as either being all about MC/S or
> explicitly state that it is
intended to affect Multiple Sessions also,
> and then address the
issues and solution for each separately. For
> example, I believe
Robert was addressing the issue from a view of
> Multiple Sessions and
if we only intended to address MC/S then I
> expect the response might
be somewhat different.
>
>
>
> Anyway, if you
could clear-up some of this, I think it would be useful
> (at least to
me).
>
>
>
> .
>
>
.
>
> .
>
> John L Hufferd
>
> Sr.
Executive Director of Technology
>
> Brocade Communications
Systems, Inc
>
> jhufferd@xxxxxxxxxxx
<mailto:jhufferd@xxxxxxxxxxx>
>
> Office Phone: (408)
333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408)
997-6136; Cell: (408) 627-9606
>
>
>
>
------------------------------------------------------------------------
>
>
*From:* Mallikarjun C. [mailto:cb_mallikarjun@xxxxxxxxx]
> *Sent:*
Friday, January 05, 2007 10:08 AM
> *To:* ips@xxxxxxxx
>
*Subject:* Re: Response Fence Flag
>
>
>
> Not really. Current draft text is intentionally
written to not have
> any dependencies on T10 dynamics. The point
is that iSCSI needs such
> a notion for succinctly describing the
proper iSCSI protocol actions
> in a few places - ACA, TMF, Persistent
reserve/Abort to name a few.
> We certainly hope it will be
approved by T10 and be a part of SAM-4
> soon, but that isn't required
per se for describing what iSCSI needs
> for its correct
behavior.
>
>
>
> IPS WG has adopted what it
needs in the past - staying ahead of T10
> review/approval cycle if
necessary. I_T nexus loss notification,
> iSCSI target/port
naming, clearing effects are a few I recall.
>
>
>
> Mallikarjun
>
>
>
>
>
> ----- Original Message ----
> From: Eddy
Quicksall <Quicksall_iSCSI@xxxxxxxxxxxxx>
> To: Robert Snively
<rsnively@xxxxxxxxxxx>; "Elliott, Robert (Server
> Storage)"
<Elliott@xxxxxx>; ips@xxxxxxxx
> Sent: Friday, January 5, 2007
8:58:47 AM
> Subject: Re: Response Fence Flag
>
> From
an earlier email I think that Response Fence is only a proposal
> in
T10 (http://www.t10.org:80/doc06.htm
>
<http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
> until this has been ratified?
>
>
>
>
Eddy
>
>
>
__________________________________________________
> Do You
Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection
around
> http://mail.yahoo.com
>
------------------------------------------------------------------------
>
>
_______________________________________________
> Ips mailing
list
> Ips@xxxxxxxx
>
https://www1.ietf.org/mailman/listinfo/ips
>
_______________________________________________
Ips mailing
list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
|
