RE: iSCSI Target Reset

["Elliott, Robert" <Robert.Elliott@compaq.com>]

It's not a very good situation when each device chooses the
interpretation of TARGET RESET that it thinks is appropriate.  
IBM's Shark might choose a different hack than Compaq's
RA8000.  How is software supposed to make sense of this?

The rule in SAM-2 is that TARGET RESET resets every logical
unit (subject to access controls, if implemented).  The fact
is that in Fibre Channel, not many multi-LUN multi-port
targets followed that rule.  The result is that software 
cannot tell what's going to happen and may have to handle
targets from each vendor differently.  This is not very 
interoperable.

Charles suggested in the T10 meeting that we allow it to 
be implemented as a no-op rather than let protocols drop 
support for it.  That doesn't help software like Windows that 
does expect certain effects - a no-op implementation 
would break clustering.  By removing it from the protocol, 
software is forced to find a suitable replacement (e.g. use 
LOGICAL UNIT RESET or switch to persistent reservations).
In Windows, this can be done at the port driver level
(STORPORT improving on SCSIPORT) or at the miniport level
(convert each target reset request into multiple LOGICAL UNIT
RESETs).

Note that other protocols like NFS and HTTP over IP don't
seem to have "server resets."

The recent SAM-2 change was expressly designed to encourage 
iSCSI and SRP to drop support for TARGET RESET.  Please don't 
keep it because you think T10 would be offended :-)

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com






> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Monday, April 23, 2001 6:31 PM
> To: cmonia@NishanSystems.com; ips@ece.cmu.edu
> 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
> > > 
> > > 
> > > 
> > > 
>