use of class 2 for tapes on FC-AL loops
Doug Hagerman, Digital Equipment, 508-841-2145, Flames to /dev/null 17-Apr-1997 1728
hagerman at miss.ENET.dec.com
Thu Apr 17 14:31:55 PDT 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* "Doug Hagerman, Digital Equipment, 508-841-2145, Flames to /dev/null 17-Apr-1997 1728" <hagerman at miss.ENET.dec.com>
*
In reference to his proposal for using Class 2 to solve the tape problem,
presumably what Jim is referring to is the use of Class 2 as described in
the FCSI profiles plus FCP plus the SSC device model. (I don't know of
any other proposals.) This is fine with me, but I would like to hear
about the following questions:
1. Would this work with current Class 3 hardware?
2. Where in FCSI or FCP is the recovery process documented? As far as I
can find there are a number of error conditions, and in every case the
response to the error is to terminate both the sequence and the exchange.
This is exactly the problem in the case of tapes. Class 2 helps detect
some of the errors, but doesn't have anything to do with the recovery.
Perhaps I just can't read; could someone help me find the appropriate
paragraphs in FCSI or FCP?
3. Using what class does one send the INQUIRY command to a LUN in and
SCC device, not knowing in advance whether it is a tape or a disk?
I think what is needed at this point is a pair of proposals, one for
Class 2 and one for Class 3, each of which purports to solve the various
difficulties. Given that we could select the less objectionable...
Doug.
----------
From: "jmcgrath at QNTM.COM\"
Sent: Tuesday, 15 April, 1997 2:57 PM
To: Douglas Hagerman
Subject: FCL Error SSWG Conference Call for Today
<<File: 4-1-97.doc>><<File: 3-18-9~1.doc>>
* From the SCSI Reflector (scsi at symbios.com), posted by:
* jmcgrath at qntm.com (Jim Mcgrath)
*
--IMA.Boundary.701721168
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
I sent out an announcement as normal last week, but I did not check
to see if it was reflected by FC at Network.Com. Indeed, it had not been
(is that reflector ever going to get back up?), so the conference call
for today has been cancelled.
The next conference call is scheduled for
Tuesday, April 29, 9am to 11 am PST.
I will send out the phone numbers in a later message.
Enclosed with this message are the minutes for the last two meetings.
The FC working group feedback last week was that some reasonably
low timeout based on a low E_D_TOV value was OK for us to work
with for sequence level error recovery. The fabric people said that
the existing value was chosen so that it was easy to hit. They
cautioned that values lower than hundreds of ms might be a problem,
especially if the delay is caused by congestion (which is time
variable), not topology.
I would like to suggest that we consider using this order of
timeout for a sequence level error detection and recovery technique.
While this restricts the time spent in the interconnect, we have
to decide on other assumptions the sender and receiver of frames for
the sequence can have on the receiver and sender respectively. That
is, the interconnect time delay is only one element that should be
used to trigger a timeout below the ULP mechanism. What assumptions
should we make about a receiver's ability to issue new buffer
credits in a timely manner? What assumptions should the receiver
make, after granting credits, about the ability of the sender to
respond in a timely manner? Are we always assuming that the non
interconnect delays are essentially 0?
The tape people gave some more presentations on problems with
tape and FC. I would like to propose (and get response from
people) the following on this issue: given our October deadline,
and the fact that none of the alternatives that address this
problem (tape operations in a non queued or queued but only 1
command deep environment, so we do not have the out of order
command problem) cleanly, why not require class 2 behavior when
talking to a tape drive?
I would like to propose the the Error SSWG adopt this solution
as the incumbant solution and make sure it addresses tha logical
problems raised by tape people. Its overwhelming advantage over
any other approach is that it is an already dfined solution. If
we can find specific faults with this approach, then we can invite
alternative proposals that address those points or are simplier
(in some sense) than class 2. My goal here is to provide closure
on this issue - we have been discussing it for far too long without
concrete proposals on the table that can lead to closure.
On link level error recovery, we still need to define the criteria
for making a decision on whether we need it (given higher level of
error recovery). For instance, is it performance? If so, under
what circumstances and what is the expected performance gain? My
philosophy is that we should entertain error recovery additions
only for a reason. We seem to have a desire to avoid ULP timeouts,
but at the end of the day it does not seem likely we need a
sequence level error recovery and a link level error recovery -
unless we find their benefits are additive, we should be trying to
simplify our life and focus on one of them.
Jim
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10
mailing list