SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: clearing SCSI objects



    On 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