RE: iSCSI: Re: iSCSI & Linked Commands

["Douglas Otis" <dotis@sanlight.net>]

Mark,

I have little doubt that what you are saying is true for Fibre-Channel.
Much of the confusion seems to stem from the choices in architectural
models.  FC found a solution selectively using CRN and reservation. iSCSI,
choosing to support multiple connections, has then required more extensive
use of serialization.  For devices that can only handle one task at a time,
linking is assured at providing the desired results within parallel SCSI.

One view with the general provisions at providing non-idem potent means of
commanding a device expands into a general discussion of ensuring
synchronization of server state.  This is an obligation of the transport
that is not met with connection allegiance alone.  There are many means of
accomplishing this goal.  With respect to linking, I was simply correcting
the language used to describe command allegiance to a connection.  Unless
linked commands are banned from SCSI, allegiance as now described for iSCSI
does not apply to the task.  As there is never more than one outstanding
command active within a linked command set, iSCSI should have no difficulty
in providing this feature.

What happens at the application and how that translates into the transport
is something the proposal is to provide.  Backup applications are behind the
paradigm shift so do not expect the application to conform to your
expectations.  From the requirement proposal, scanners and printers and
mechanical loaders will need workable solutions within iSCSI.  Should the
transport be able to understand the commands for all of these devices, some
of these devices, and what of devices using vendor unique commands or wholly
new commands?  In my view, the transport should not respond to or modify the
SCSI layer.  There are techniques that make no assumptions about the SCSI
layer content.

Doug

> Doug,
>
> Whether or not a device uses relative addressing has nothing to do with
> command linking. A LOCATE command moves the head, and a following READ
> reads the data. Using command linking, relative addressing, etc. does
> not protect the sender of the above commands from another command, sent
> by that initiator or any other, which may move the head, and thus cause
> the original READ to get the data from the wrong place. There is no
> protection between the first and any subsequent commands under command
> linking. Thus, the proper way to use LOCATE and READ is with
> RESERVE/RELEASE. I assume that it was in order to settle this confusion,
> that FC-TAPE decided to ban linked commands.
>
> -mark
>
> Douglas Otis wrote:
> >
> > Stephen,
> >
> > Unlike random access devices, sequential access devices operate with
> > relative addressing.  For random access devices, this is a seldom used
> > option.  There is a requirement to bind commands together to
> ensure order of
> > execution on these devices.  By popular, you mean not sequential?
> >
> > Doug
> >
> > > Julian,
> > >
> > > > According to your logic no FCP implementation can use
> linked commands?
> > > > Is this true for all OS's?  Is it a verified fact or foloklor?
> > >
> > > In my experience it's fact.  I have never used a SCSI stack which both
> > > supported AND used linked commands.  Like some others here, I always
> > > assumed AIX might :^) Ralph has pointed out that T10 is well aware
> > > that the feature is not popular.  There are other ways of
> > > accomplishing the same thing that are less likely to blow up in your
> > > face.
> > >
> > > > Is it so also for the new MS StorPort driver?
> > >
> > > I don't know, but I'd be really surprised if they did use linked
> > > commands.  You have to be pretty nuts to rely on a feature that's not
> > > even exercised by most SCSI implementations.
> > >
> > > Steph
> > >
>
> --
> Mark Mokryn      SANgate Systems Inc.      mark@SANgate.com
> Phone: +972-9-8919821                Mobile: +972-54-270030
> Fax: +972-9-8919449                  http://www.SANgate.com
> P.O. Box 1486 41 Hameyasdim St., Even Yehuda 40500 Israel
>