Logical unit groups and optional target reset

Tom Coughlan coughlan at missioncriticallinux.com
Fri Dec 22 06:27:52 PST 2000

* From the T10 Reflector (t10 at t10.org), posted by:
* Tom Coughlan <coughlan at missioncriticallinux.com>

I do not object to making Target Reset optional.  The concern I have is
about making Target Reset optional for an entire protocol standard.  I
think that each transport should provide a standard way to deliver the
Target Reset from the initiator to the target. The target may or may not
implement the function. 

If you are unfortunate enough to have initiator software that is
injudicious in its use of Target Reset on shared targets, then you
disable it at the target.  If you have initiator software that uses
Target Reset appropriately, to recover a device that can not be
recovered in any less-disruptive way, then the functionality is

I agree with Ralph that this topic does not belong in the command sets.

Tom Coughlan
Mission Critical Linux
tel: 978-606-0262
coughlan at missioncriticallinux.com

"Elliott, Robert" wrote:
> Today all devices on all transports are required to support
> TARGET RESET, so the target design cannot choose to ignore
> it.  We could change SAM-2 to let command sets dictate,
> so new command sets like SBC-2 and SSC-2 could mark it as
> optional.  However, command set standards don't normally
> deal with task management features.
> A device can certainly implement a vendor-unique target reset,
> even if the transport doesn't support it.  This would prevent
> standard software from using it (e.g. to clear reservations)
> but leave it accessible for for lab debug.
> ---
> PC: Robert.Elliott at compaq.com
> UNIX: relliott at unixmail.compaq.com
> > -----Original Message-----
> > From: Tom Coughlan [mailto:coughlan at missioncriticallinux.com]
> > Sent: Thursday, December 21, 2000 8:55 AM
> > Subject: Re: Logical unit groups and optional target reset
> >
> > I agree with the goal of encouraging the implementation and use of
> > Logical Unit Reset. But, I'm not sure that dropping support for Target
> > Reset in future interconnects is a good idea.  Target Reset is the
> > medium weight hammer, between Logical Unit Reset, and resetting the
> > whole environment by, say, resetting the host bus adapter.
> >
> > I accept that there may be some target designs where resetting all the
> > logical units does all there is to do, and there is no point in
> > implementing a Target Reset.  But isn't it reasonable to
> > expect that, in
> > some target designs, a Target Reset will clear a hung
> > something-or-other, that is not cleared by Logical Unit Resets?
> >
> > Shouldn't the decision to implement Target Reset be made based on the
> > design of the target, rather than the interconnect?
> > --
> > Tom Coughlan
> > Mission Critical Linux
> > tel: 978-606-0262
> > coughlan at missioncriticallinux.com
> >
> > "Elliott, Robert" wrote:
> > > 01-015r0 Making Target Reset optional in SAM-2
> > >
> > > This would let new protocol standards like SRP and iSCSI
> > drop support for
> > > Target Reset.  Target Reset is very disruptive in a SAN
> > environment where
> > > different logical units on one target device are being used
> > by different
> > > initiators.  Logical Unit Reset is a better tool.
> > >
> > > SRP and iSCSI drivers can map legacy Target Reset requests
> > into Logical Unit
> > > Resets for every logical unit the initiator is using.  This avoids
> > > disrupting other initiators using other logical units.  Its
> > absence from
> > > future standards may help wean software from issuing Target Resets.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list