|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: clearing SCSI objectsOn Mon, 5 May 2003, Eddy Quicksall wrote: > If you don't worry about it, you will either have to: > > 1) have lots of initiator structures available > 2) not support multiple Initiator Ports > 3) not be fully SCSI compliant > > The Microsoft Initiator will use a different ISID each time it logs on. It > will log on with each boot and there is no guarantee that it will use the > same ISID set with each boot. I think multiple applications will also be > able to login at the same time ... each with a different ISID. If they login > and logout with execution, you may run our of structures ?? Huh? I was suggesting not worrying about keeping resources around to tell an initiator it lost the I_T nexus when it already knows it lost the I_T nexus. How will that mean I'll run out of resources? Take care, Bill > -----Original Message----- > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > Sent: Monday, May 05, 2003 6:50 PM > To: Eddy Quicksall > Cc: David Black (Black_David@emc.com); ips@ece.cmu.edu > Subject: RE: iSCSI: clearing SCSI objects > > On Sun, 4 May 2003, Eddy Quicksall wrote: > > > David, > > > > I'm wondering what other targets are doing about this. Was it thought > about > > during the design phase? > > Our (Wasabi's) target isn't going to do this, unless there is a strong > indication that it's needed/required for certification. I see no real > reason to do this as it's not conveying any value. > > > I'm thinking I will keep an LRU list and if I run out of structures to > > handle SCSI Initiator Ports (and there are no persistent reserves > > outstanding), I'll just discard the oldest structure. That will give a > power > > on reset UA if that InitiatorName+ISID is used again. > > > > Does that seem like a logical solution? > > I think it's far simpler to not worry about it, or be clearer about when > we worry about it. SAM was written with parallel and FC SCSI in mind. > While there are obvious references to iSCSI, we are only now gaining > experience about what needs tweaking in light of iSCSI. > > I'd say start with asking why SAM says the target needs to set a UA, and > see if that applies here. It's my understanding that parallel SCSI has no > way for the target to asynchronously just tell the initiator something. > Likewise, the initiator has no way to directly notice the loss of an I_T > nexus. > > iSCSI, though, doesn't have those limitations. For instance, we can send > Asynchronous messages with SCSI sense data. We also have one or more TCP > connections, and rules for adding connections to a session. The up-shot is > that the initiator will realize if it looses the I_T nexus due to > transport issues. For instance, when it goes to add a connection to a > session, it will be told that no such session exists (top of page 60 in > draft 20) -> the session (I_T nexus) is dead. Alternately if the initiator > chooses to do session reinstatement, it knows it is loosing the old I_T > nexus (that's what it's telling the target to do, after all :-) . > > So I'd think that the best thing to do here is push back on SAM for iSCSI, > and ignore the need to assert the UA for I_T nexus loss in the cases where > the initiator will notice it itself. > > Note I'm hedging my words, since I think we still need a UA for nexus loss > if it happens in a way the initiator won't notice. > > Thoughts? > > Take care, > > Bill >
Home Last updated: Mon May 05 21:19:23 2003 12573 messages in chronological order |