|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: LUN in a pingThe reason for having the LUN in all incoming messages is not to help discovery but to enable "federated" targets to issue their TTTs without coordination and add the LUN so that any outgoing message will be "routed" to the right box. However we realized early on that the checking of the validity of the LUN by an initiator should be left to the implementer. That is why section 3.2.4.3 mandates testing only where consistency with ITT is involved. Julo
Hello Julo, For those of us that weren't here 18 months ago can you refresh us on your explanation or point us to where it is since I too wonder why a SCSI Target would not use the mechanisms it already has in place to notify an initiator of a LUN inventory change? Thanks, Ken Craig -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, January 23, 2003 8:47 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison Subject: RE: iSCSI: LUN in a ping Eddy, We all appreciate you opinion - but this has been hotly debated more than 18 months ago. And I recall sending you an explanation regarding the middle boxes and how they handle the LUN for routing in a "clustered" target. And your comment about a "requirement with no good reason" besides being derogatory does not add any value to the discussion. Julo
For that, wouldn't the target generate REPORTED LUNS DATA HAS CHANGED (3F/0E)? It is my opinion that this is just another requirement that has been put on the target for no good reason. It should be up to the target as to if the LUN field has meaning and the initiator should be the one that has a requirement to echo the value. Eddy -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, January 22, 2003 1:52 PM To: Eddy Quicksall; Julian Satran; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping The initiator might try to rediscover the LUN topology if it sees a NOP from a LUN that it previously thought was not present. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Wednesday, January 22, 2003 10:28 AM To: Julian Satran; Eddy Quicksall; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping Yes, I remember that but the necessity for the target to set it should be up to the target because the initiator should not be trying to interpret it (it should only be required to echo it). Is there a case where the initiator will interpret the LUN? Eddy -----Original Message----- From: Julian Satran [mailto:julian@cs.haifa.ac.il] Sent: Wednesday, January 22, 2003 12:43 AM To: 'Eddy Quicksall'; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping TTT & LUN uniquely identify the "origin" (if target is a "composite" each of the parts can issue their own TTTs - no coordination needed). Regards, Julo -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Eddy Quicksall Sent: 22 January, 2003 00:07 To: ips@ece.cmu.edu Subject: iSCSI: LUN in a ping Does anyone know why we added "the LUN must be valid" for a target initiated ping? It would seem that it is N/A when the ping is just being used to checkup on the connection. What will the initiator do with the LUN anyway? 10.19.3 LUN A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff). Eddy mailto: Eddy_Quicksall@iVivity.com
Home Last updated: Fri Jan 24 03:19:08 2003 12250 messages in chronological order |