SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Target Reset handling



    
    
    Mallikarjun,
    
    How about having two different function:
    
    target warm-reset (connections stay) and target cold-rest (connections get
    also reset)?
    
    Julo
    
    "Mallikarjun C." <cbm@rose.hp.com> on 03/09/2000 06:07:07
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  Re: Target Reset handling
    
    
    
    
    Julian,
    
    Let me try again, I was arguing that the protocol stack (I assume you
    mean the state information in various layers by this) and the TCP
    connections be *not* reset - since I do not see a need for the SCSI
    transport mechanism to be reset/cleared in the context of "SCSI target
    reset".  I would again request your attention on the FC precedent, and
    the software expectations of a confirmed target reset.  Logging in after
    an arbitrary "long time" and assuming the target reset to be complete is
    simply unreliable.
    
    I do not see a need for a special "iSCSI reset".  I believe that the
    SCSI target reset task management request is completely adequate to
    address our requirements.  All I am proposing is a change in its current
    definition in view of the various reasons I had already stated, and the
    benefits of making this change (not the least of which is SAM-2
    compliance).  Addition of a new reset mechanism would also defeat our
    common goal to keep a fairly lean protocol.
    
    The question of security context needs to addressed regardless of the
    SCSI transport behavior on a target reset.  If security context is being
    designed as part of the transient operating environment (as opposed to
    say, creating/modifying mode pages), then my first guess would be that
    it has to be reset as well to initial values, on a target reset.  I am
    not sure what you implied, but are you suggesting that the security
    context cannot be reset with TCP connections living across a SCSI target
    reset?  Or, did I totally miss something?
    
    Regards.
    
    Mallikarjun
    M/S 5601
    Networked Storage Architecture
    HP Storage Organization
    Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    julian_satran@il.ibm.com wrote:
    >
    > Mallikajun,
    >
    > Assuming that we leave the connections on - how would you suggest we
    reset
    > the protocol stack and the connections?
    >
    > Is adding a new iSCSI reset better?
    >
    > Should the target imply a reset when all connections drop and a new
    session
    > get's established or a long time passes?
    >
    > What happens to the security context across a reset?
    >
    > I have the feeling that answers to those questions will complicate the
    > reset handling
    > far beyond what the technical community will find acceptable.
    >
    > Julo
    >
    > "Mallikarjun C." <cbm@rose.hp.com> on 01/09/2000 20:31:39
    >
    > Please respond to cbm@rose.hp.com
    >
    > To:   ips@ece.cmu.edu
    > cc:    (bcc: Julian Satran/Haifa/IBM)
    > Subject:  Re: Target Reset handling
    >
    > Julian,
    >
    > I agree with you that the interactions should be left as simple
    > as possible, but I strongly believe that a response to a target
    > reset is highly desirable and very useful.  Besides, my reading
    > of SAM-2 (as quoted below) indicates that a response is required.
    >
    > While SAM-2 leaves the definition of the target reset process to
    > the specific SCSI protocol and interconnect, I would argue that in
    > the case of iSCSI, resetting the entire TCP/IP stack and tearing
    > up the TCP connections should not be necessary.  It would seem that
    > the SCSI operational portion (task manager, device server(s), and
    > the tasks themselves) should be affected by a SCSI target reset.
    > As I recall, this is the approach FC target implementations took
    > leaving the process login sessions intact.  Having the TCP connections
    > operational would allow us to -
    >      - reliably deliver the AEN to all the iSCSI-logged-in initiators.
    >      - deliver a response to target reset task mgmt request
    >
    > There's a fair amount of SCSI/LVM software that relies on a reliable
    > target reset confirmation, and an out-of-band confirmation of the
    > same would not go well with it.
    >
    > Regards.
    > --
    > Mallikarjun
    > M/S 5601
    > Networked Storage Architecture
    > HP Storage Organization
    > Hewlett-Packard, Roseville.
    > cbm@rose.hp.com
    >
    > >Mallikarjun,
    > >
    > >We assumed that a reset for a controller including such a complex piece
    > >of code/hardware as protocol stack is never complete without resetting
    it
    > >too.
    > >making AE signalling mandatory is not big help as they might get lost
    > >if done before the connections break. But if the group feels we should
    > make
    > >it mandatory we will.
    > >
    > >For any simple minded (minimalist design) a protocol function
    > >that does what a reset button would do should be enough.
    > >
    > >For complex controllers you can choose to:
    > >
    > >- record the reset results in NV store and report them during the next
    > >session
    > >or even make reading this log in a sense mandatory through an ACA
    > >
    > >- report the event through a vendor specific text response to the next
    > >login
    > >
    > >- use management interfaces (SNMP)
    > >
    > >I personally am inclined to think that the "in-band" rest should be left
    > >as simple as possible (but not simpler!) and out-of-band communication
    > >should
    > >be used to check the process.
    > >
    > >Regards,
    > >Julo
    > >
    
    
    
    


Home

Last updated: Tue Sep 04 01:07:35 2001
6315 messages in chronological order