Re: Target Reset

["John Hufferd" <hufferd@us.ibm.com>]

Eddy,
All that might be true of NT, but the Shark, and Symmetrix have many other
clusters and non clusters connected to it.  The shark for example has 32
different SCSI connections.  A target reset will effect every one, not just
a specific NT cluster.

.
.
.
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


"Eddy Quicksall" <ESQuicksall@hotmail.com> on 04/23/2001 02:02:33 PM

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  Re: Target Reset



Actually, I made an assumption but did not make a suggestion; I only wanted
to bring up the point that there has to be some way to emulate what NT is
doing and at this time.

On the current NT MSCS, there will only be 2 hosts on the target. I have
heard that they have a multi-node cluster but I don't know how they do a
challenge there (I suspect that they don't use RESET).

Regarding the number of LUs, NT it is limited to a small number of LUs on a
target and a small number of targets on a bus.

Eddy

----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Eddy Quicksall" <ESQuicksall@hotmail.com>
Cc: <ips@ece.cmu.edu>
Sent: Monday, April 23, 2001 4:07 PM
Subject: Re: Target Reset


>
> Eddy,
> A target like an IBM Shark or EMC Symmetrix will have thousands of LUs
and
> 10s to 100s of Hosts connected to it, and you want to reset the whole
> Target?  I do not think that is a good idea.  Perhaps Task Reset or LU
> reset etc. but not Target Reset.
>
> .
> .
> .
> 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
>
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 04/23/2001 09:44:05 AM
>
> To:   "Dillard, David" <david_dillard@adaptec.com>, John Hufferd/San
>       Jose/IBM@IBMUS
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: Target Reset
>
>
>
> I am wondering how clustering will work on NT without some sort of reset.
>
> On parallel SCSI, NT will issue a SCSI BUS RESET to break reservations
> during a challenge for the quorum drive.
>
> On iSCSI, there is no full equivalent to the SCSI BUS RESET so I would
> assume the NT driver would have to issue a TARGET RESET to each target
that
> it is supporting.
>
> How would you propose this would be done without a TARGET RESET?
>
> Eddy
>
> ----- Original Message -----
> From: "John Hufferd" <hufferd@us.ibm.com>
> To: "Dillard, David" <david_dillard@adaptec.com>
> Cc: <ips@ece.cmu.edu>
> Sent: Sunday, April 22, 2001 3:20 PM
> Subject: RE: Target Reset
>
>
> >
> > This is at least better.  But I do not have the issue of it being
vendor
> > unique.  This is a shut down and restart of the complete Target, and
will
> > probably be part of the vendors' operator console or their own remote
> > support functions, it is not clear that it needs to be a general
> management
> > function that works the same on all iSCSI Storage Controllers.
> >
> > Many of the major Storage Controller do not support this feature today.
> >
> > I do not believe that most SNMP implementations are very secure.  Most
> > folks do not want to have a changeable MIB until they have secure SNMP,
> and
> > even though there is a version of SNMP that has security features, this
> has
> > not been well supported.
> >
> > I do NOT think that Target Reset should be in the base iSCSI protocol,
> but
> > I think it is reasonable to hold this discussion apart from the base
> > protocol document, and the question should be asked if this is a
general
> > management function or a vendor specific console or remote support
> > function.
> >
> >
> >
> > .
> > .
> > .
> > 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
> >
> >
> > "Dillard, David" <david_dillard@adaptec.com>@ece.cmu.edu on 04/22/2001
> > 08:13:49 AM
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  RE: Target Reset
> >
> >
> >
> > John,
> >
> > I understand the danger of issuing a target reset and I agree that it
> > should
> > not be a part of the an initiator's normal error recovery procedure.
> > However, looking at this from a management perspective I'd like to see
a
> > standardized way of resetting a target.  I don't want to see a variety
of
> > vendor unique methods of resetting targets sprout up.
> >
> > If resetting a target using the protocol is not desirable from your
> > perspective would incorporating this feature into the MIB be
acceptable?
> > (MIBs are for management after all)
> >
> > ----------------------------------------------------------------
> > David Dillard                          david_dillard@adaptec.com
> > Management Software Group
> > Adaptec, Inc.                          www.adaptec.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > Sent: Sunday, April 22, 2001 4:59 AM
> > To: ips@ece.cmu.edu
> > Subject: Target Reset
> >
> >
> > I thought we had a number of discussion previously about Target Reset
> (Warm
> > or Cold).  I thought there was general feeling that this command is so
> > dangerous that it should not be supported by iSCSI.  The long distance
> > capability of iSCSI makes the risks involved unmanageable.  There
should
> > only be an Admin way to do this.
> >
> > Some folks have said that we could permit it and have special
> authorization
> > etc.  This would probably cause a separate section in the spec. to
define
> > the authorization approach,  and what ever other security is needed to
> > prevent this from inappropriately being used.  All for what purpose?
> This
> > can not be part of error recovery from a normal initiator.  The wide
> spread
> > effect is too great for that.
> >
> > I would like to hear from the list about their feeling on this item.
> >
> >
> >
> > .
> > .
> > .
> > 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
> >
> >
> >
> >
>
>
>
>