SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Target Reset



    
    David,
    you described the action in FC terms.  In iSCSI terms, I think the Target
    Device would be a complete Symmetrix.  Do you think that is correct?  What
    does Symmetrix do today to support Target Reset?  And how do you think it
    should act in the future?  Surly you do not want the complete controller
    reset, do you?
    
    What type of flexibility do you think T10 gives you in this situation?
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Internet address: hufferd@us.ibm.com
    
    
    Black_David@emc.com@ece.cmu.edu on 04/23/2001 04:31:24 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   cmonia@NishanSystems.com, ips@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI Target Reset
    
    
    
    I agree with Charles that this is an implementation
    issue.  If a Shark wants to reset all 32 adapters
    when it receives a Target Reset on one of them, that's
    a Shark implementation decision.  It's completely valid
    to reset only the adapter that the Target Reset is
    received on (common Fibre Channel behavior) or
    only the iSCSI target to which the Target Reset is
    addressed if there's more than one Target behind
    the adapter.
    
    As for leaving things out of iSCSI - the default modus
    operandi should be to put in everything that's described
    in SAM2 unless we can convince T10 to take the feature
    out of SAM2.  Let's not go deciding to cast things out
    of SCSI on T10's behalf.
    
    Thanks,
    --David
    
    > -----Original Message-----
    > From:   Charles Monia [SMTP:cmonia@nishansystems.com]
    > Sent:   Monday, April 23, 2001 7:12 PM
    > To:     ips@ece.cmu.edu
    > Subject:     RE: iSCSI Target Reset
    >
    > Hi:
    >
    > These seem to be implementation decisions. I don't see how that justifies
    > removing support from the protocol.
    >
    > Charles
    >
    > > -----Original Message-----
    > > From: John Hufferd [mailto:hufferd@us.ibm.com]
    > > Sent: Monday, April 23, 2001 2:34 PM
    > > To: Santosh Rao
    > > Cc: ips@ece.cmu.edu
    > > Subject: Re: iSCSI Target Reset
    > >
    > >
    > >
    > > Absolutely not,  Why would we think that impacting 32 different other
    > > initiators is an OK thing to do.  By the way there are lots
    > > more Initiators
    > > possible with FC on Shark, and would hope that there would be
    > > even more
    > > with iSCSI.
    > >
    > > I have been told that these large Storage Controllers do not
    > > support Target
    > > Reset today.  So I see no loss in not supporting such an item in iSCSI
    > > especially since many Initiators will be beyond even the distances and
    > > mischief that is possible with FC.
    > >
    > > .
    > > .
    > > .
    > > John L. Hufferd
    > > Senior Technical Staff Member (STSM)
    > > IBM/SSG San Jose Ca
    > > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > > Internet address: hufferd@us.ibm.com
    > >
    > >
    > > Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 04/23/2001
    > > 01:24:02 PM
    > >
    > > Sent by:  owner-ips@ece.cmu.edu
    > >
    > >
    > > To:   ips@ece.cmu.edu
    > > cc:
    > > Subject:  Re: iSCSI Target Reset
    > >
    > >
    > >
    > > "Dillard, David" wrote:
    > > >
    > > > When will STORPORT be generally available?  The latest
    > > STORPORT document
    > > > that I found on the MS web site is version 0.6a, dated
    > > March 18, 2001.
    > > > Given this it seems like STORPORT might not be available
    > > soon.  In that
    > > case
    > > > do you know what happens with the current drivers?  Are we
    > > going to be
    > > > telling customers that if they want to use iSCSI and NT
    > > clustering they
    > > have
    > > > to update to Whistler?
    > >
    > >
    > > [One would hope that this list does not turn into a Microsoft
    > > release/product discussion mailing list (?) ]
    > >
    > > Without going into specifics of A certain O.S., does it suffice to
    > > require that iSCSI not break existing legacy SCSI applications ?
    > >
    > > If the above is a valid requirement, then, knowing that legacy
    > > applications continue to use SCSI-2 Reserve/Release and the
    > > target reset
    > > as a mechanism of breaking SCSI-2 reservations, should'nt
    > > iSCSI continue
    > > to support the target reset ?
    > >
    > > - Santosh
    > >
    > >
    > >
    > >
    
    
    
    


Home

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