RE: iSCSI Target Reset

["Jim Hafner" <hafner@almaden.ibm.com>]

John,

I'm really getting lost in this thread, but let me throw in my 2 lire.

Has anybody read the latest draft of SAM-2 rev 16? It says:
(a)Target Reset is not more than a set of Logical Unit Resets (see 6.6)
[Earlier drafts use the term "hard reset"-- this is no longer there.]
(b) Target Reset shall only affect the logical units to which the initiator
has access controls rights (see 6.0) [this is exactly what Shark does
though their "access controls" are pre-standard]

In short, I think we've spent a lot of time debating an issue that is no
longer a problem: the undesirable side effects of Target Reset just aren't
in the spec any more!

There *is* language that Logical Unit Reset "shall perform any additional
functions required by the applicable standards" (namely, the protocol
standards).

So, we
(a) can allow Target Reset in iSCSI without major concerns (but it would be
nice to "discourage it's use" as mentioned in SAM-2, rev 16, 6.6)
(b) should state explicitly that Logical Unit Reset has no additional
effects in iSCSI beyond those specified in SAM-2, rev 16, 5.7.7.


Jim Hafner


John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 04-26-2001 01:24:17 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI Target Reset




I received the following statement from the IBM Shark development team.

" For Fibre Channel, Shark supports Target Reset and it is used by almost
all the hosts as well.

Shark supports Target Reset by resetting all the LUNS that are configured
to the host that issues
the Target Reset.   The Target Reset, therefore, will not affect the LUNs
seen by other initiators,
unless they are in sharing the same LUNs. "

Therefore, it probably make some since to state, in the draft, that this
kind of approach should be considered by iSCSI implementers.

I do not think this is a large controller only problem, since with iSCSI,
lots of different desktop and Laptops will be getting at RAID arrays, which
might have previously been attached to only 2 Host via SCSI BUSes or a few
more hosts with Fibre Channel.

IOW, Target Reset has a larger impact then before, even on Storage
controllers that are in the "Mid Range" (and lower), which previously may
not have even worried about the issue.

So the mention of an approach such as the above might be a useful note in
the Spec.

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


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 04/26/2001 12:41:04 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI Target Reset





I agree that this is an implementation decision.  However I wonder it it
won't be fair to tell the guy trying to do reset that although everything
is fine the reset was not performed - and do this in a way that does not
harm legacy initiators.

Julo

Black_David@emc.com on 24/04/2001 02:31:24

Please respond to Black_David@emc.com

To:    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
> >
> >
> >
> >