|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: SCSI Format/Copy CDB supportAh, I see the confusion. In that section, "reissued" refers to reissuing a command due to holes in the command sequence (e.g., digest failure, connection drop). In the scenario of interest, the command is not being reissued by iSCSI - SCSI is aborting the old command based on the task tag and issuing a new command which will get a new CmdSN (iSCSI will probably have long since forgotten the CmdSN assigned to the original command). A sentence or two to clarify this wouldn't hurt. --David > -----Original Message----- > From: Amir Shalit [mailto:amir@astutenetworks.com] > Sent: Friday, January 25, 2002 7:03 PM > To: Julian Satran > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > Julo, > > I was talking about initiator aborting the command > ,say two hours after it was sent, and than reissue > the same command with the old CmdSN (according to > the spec). > > I agree with you that the spec covers all other cases > since once a command is delivered, CmdSN doesn't > matter much and ITT or TTT are used to match the > task. > > Amir > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 2:14 PM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); Julian Satran; owner-ips@ece.cmu.edu > Subject: RE: SCSI Format/Copy CDB support > > > > Amir, > CmdSN is completely secondary in abort task. > The main element is the Initiator Task Tag. > If ITT is not found at abort then the target, under some > cirscumstances, > will look for a hole at CmdSN to fill it or will answer > negatively the Task > Abort. > > Julo > > > > "Amir Shalit" > <amir@astutenet To: Julian > Satran/Haifa/IBM@IBMIL > works.com> cc: "ips@ece. cmu. edu > \(E-mail\)" <ips@ece.cmu.edu>, > <owner-ips@ece.cmu.edu> > 25-01-02 18:49 Subject: RE: > SCSI Format/Copy > CDB support > > > > > > > Julo, > > I agree with you on (2). > > Section 2.2.2.1 is saying: > "A numbered iSCSI request will not change its allocated CmdSN > regardless of the number of times and circumstances in which it is > reissued." > > A long duration SCSI command may be aborted by a task management > command and than reissued by iSCSI with a stale CmdSN. > > Amir > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, January 25, 2002 1:21 AM > To: Amir Shalit > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: Re: SCSI Format/Copy CDB support > > > Amir, > > The draft says in several places that CmdSN is not > important after the > task gets to SCSI. > On 2 yes you might be right but that is purely an implementation > issue. Format commands do not time-out > at SCSI level and iSCSI has no cause to e "nervous" - nothing is > expected. > > > Julo > > > > > "Amir Shalit" > <amir@astutenetworks.com> To: > "ips@ece. cmu. edu > Sent by: owner-ips@ece.cmu.edu \(E-mail\)" <ips@ece.cmu.edu> > cc: > Subject: > SCSI Format/Copy > 25-01-02 02:10 CDB support > > > > > > > > I see a few problems in implementing the format/copy > commands over > iSCSI > > 1) CmdSN may wrap between command and response (assuming multiple > LUNs) > > 2) iSCSI keepalive NOPs may be required to keep the > connection open > during format > > > > > > >
Home Last updated: Sat Jan 26 14:17:57 2002 8500 messages in chronological order |