|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] remove-----Original Message----- From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com] Sent: Monday, August 06, 2001 2:23 PM To: Elliott, Robert; ips@ece.cmu.edu Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data Then what was the purpose of giving them separate fields and eliminating the S bit? Eddy ----- Original Message ----- From: "Elliott, Robert" <Robert.Elliott@compaq.com> To: <ips@ece.cmu.edu> Sent: Thursday, August 02, 2001 6:04 PM Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data > My view: > If a non-zero response code is present, the Status field is undefined > and the response data contains all information about the error (fed > from the iSCSI layer). > > If the target is capable of reporting a Status, then the response > field is zero and the sense data contains all information about the > error (fed from the SCSI layer, which might communicate with the > iSCSI layer internally to figure out some of the information). > > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > > > > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@brocade.com] > > Sent: Thursday, August 02, 2001 4:39 PM > > To: 'cbm@rose.hp.com'; Elliott, Robert > > Cc: 'ips@ece.cmu.edu' > > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data > > > > > > I am not sure that complete removal of the response codes > > is the best approach. There are some things > > that SCSI devices can know nothing about, and only TCP links > > can know about. There are other things that iSCSI state machines > > know about that logical units do not know about (usually software > > generated inconsistencies in the protocol procedures). These are > > natural candidates for response codes. Note that vendor > > specific is a synonym for non-interoperable and also for > > undesirable. It is far better to reserve anything like that, > > since the behavior in the presence of a vendor specific value > > is not defined. While it is clear that may response codes should > > move over to CHECK CONDITIONS, I think that there are > > still some protocol related response codes that will be required. > > > > Bob > > > > -----Original Message----- > > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > > Sent: Wednesday, August 01, 2001 9:06 PM > > To: Elliott, Robert > > Cc: 'ips@ece.cmu.edu' > > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data > > > > > > Robert and all, > > > > As the one who suggested that wording into the draft, let me > > add some comments. (Please see > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html > > for my initial proposal.) > > > > > I suggest removing the CHECK CONDITION status and additional sense > > > code linkage and leave the SCSI status undefined if the iSCSI > > > response is nonzero. > > > > I agree, as Steph already alluded to in a separate email, the ideal > > solution appears to: > > a) drop the response code *definitions* (ie. leave > > room for vendor-unique codes) altogether, and > > b) continue to specify the right SCSI CHECK CONDITION > > (ASC, ASCQ) values for the iSCSI error events (such > > as digest failures). > > > > As I said in the earlier referenced message "mandate a standard > > SCSI CHECK CONDITION on these errors with the current response codes > > acting as detailed descriptions.". But you bring up a good point > > that this "detailed descriptions" may be violating SAM-2's > > expectations. > > > > > Forcing the iSCSI layer to fill in those fields seems to break the > > > layering model. > > > > I disagree. If the affected SCSI task can be reliably ascertained > > by the target, it appears highly desirable to report the status > > using a SCSI CHECK CONDITION. Target iSCSI layer has to internally > > terminate the pre-instantiated SCSI task anyway informing its SCSI > > layer of the fact. Besides, there are precedents in FCP-2 for similar > > cases where the task is identifiable. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > "Elliott, Robert" wrote: > > > > > > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI > > > response codes to various CHECK CONDITION status additional > > > sense codes: > > > > > > "0x01 Target Failure > > > ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE > > > 0x02 Delivery Subsystem Failure > > > ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED > > > 0x03 Unsolicited data rejected > > > ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR > > > 0x04 Not enough unsolicited [data] > > > ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR > > > 0x05 SNACK rejected [Command in progress] > > > ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED > > > > > > As listed above, each defined response code MUST be used > > (under the > > > conditions described in the 'Reason' field), only when the > > > corresponding SCSI CHECK CONDITION is signaled, to convey > > additional > > > protocol service information. A SCSI CHECK CONDITION with the ASC > > > and ASCQ values as tabulated MUST be signaled by iSCSI targets for > > > all the instances in this document referring to usage of > > one of the > > > above defined response codes." > > > > > > No other SCSI protocol does this. iSCSI seems to be granting the > > > SCSI-level status a priority over the iSCSI-level response data. > > > I think the other protocols treat the response data as more > > > important; if the response data indicates a problem, the SCSI layer > > > is considered broken and the SCSI status is undefined. > > > > > > Forcing the iSCSI layer to fill in those fields seems to break the > > > layering model. > > > > > > I suggest removing the CHECK CONDITION status and additional sense > > > code linkage and leave the SCSI status undefined if the iSCSI > > > response is nonzero. > > > > > > This is compatible with SAM-2, which only requires status > > be returned > > > when the service response is TASK COMPLETE (SAM-2 revision 18 > > > section 5.3.1): > > > "Status shall be sent from the logical unit to the application > > > client whenever a command ends with a service response of > > > TASK COMPLETE or LINKED COMMAND COMPLETE." > > > > > > Furthermore, SAM-2 requires that status be ignored when the service > > > response indicates an error (SAM-2 revision 18 section 5.1): > > > "Status: A one-byte field containing command completion status > > > (see 5.3). If the command ends with a service response of > > > SERVICE DELIVERY OR TARGET FAILURE, the application client > > > shall consider this parameter to be undefined." > > > > > > I think iSCSI's current wording may violate this rule. > > > --- > > > Rob Elliott, Compaq Server Storage > > > Robert.Elliott@compaq.com > > >
Home Last updated: Tue Sep 04 01:04:05 2001 6315 messages in chronological order |