Re: Tape drives and iSCSI

[julian_satran@il.ibm.com]

Dave,

Thanks a lot for your insights.  We will do our best to have recovery
flexible enough to offer at least the same level as FCP-2.  The added
benefits of connection failover and dynamic bandwidth allocation
should keep iSCSI competitive in bot LAN and WAN.

Regards,
Julo

"Dave Peterson" <dap@cisco.com> on 12/04/2001 02:06:31

Please respond to "Dave Peterson" <dap@cisco.com>

To:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
cc:
Subject:  Tape drives and iSCSI





Don't believe a tape backup application model will add much value to the
discussion.
Here's my view:

Tape Requirements
-----------------
1. Data integrity
2. Data integrity
3. Data integrity
4. Perform successful uninterrupted backup (within backup window is a big
plus)

Tape Specifics
--------------
Large record sizes are recommended for performance. The largest (typical)
record size is 256KB.
Using a default DataPDULength = 8192 would require 32 data PDU's.
A typical higher-end head-to-tape transfer rates = 10 MB/sec resulting in a
backup rate of ~36 GB/hour.

Ramblings& Tidbits
------------------
FCP-2 error detection and recovery is implemented by at least one high-end
tape drive vendor (and they have a significant advantage over other
vendors,
i.e., their backup will not fail due to a FC link-level error).

SCSI level timeout and retry is highly dependent on the backup application.
One must first determine the state/position of the tape drive before
proceeding. Tools such as READ POSITION and LOCATE are in place for the
backup app to attempt recovery from an error. Problem has been few backup
vendors have yet to implement them (but things are getting better). Thus
FC-TAPE was born and the error detection and recovery mechanism was rolled
into FCP-2 as a standard. FCP-2 provides tools to determine the
state/position of the tape drive below the SCSI level allowing a "best
effort" attempt to complete the exchange/command and not return an error to
the application. At this point in time this is what is important, i.e., DO
NOT RETURN AN ERROR TO THE APPLICATION IF AT ALL POSSIBLE.

Refer to Matt Wakeley's I/O (command) recovery write-up for a description
of
iSCSI error recovery that should be used as a starting point. Maybe this
has
already been done, I'm not involved in the error recovery group. What we
need is the ability to detect an error and recovery below the SCSI level
(i.e., the iSCSI transport level). Any further granularity is not needed
especially due to the low error rates that will be encountered.

Regarding tape devices and maintaining state, FC-TAPE enabled drives have
the following requirements:
For non-tagged command queuing operations, the target shall retain the
Exchange information until
a) the next FCP_CMND IU has been received for that LUN from the same
initiator;
b) an FCP_CONF IU is received for the Exchange; or
c) after RR_TOV times out.
For tagged command queuing operations, the target shall retain Exchange
information until
a) an FCP_CONF IU is received for the Exchange; or
b) after RR_TOV times out.

There is a work in progress for a new tape model in the T10 SSC-2 working
group. This new model will allow for a simpler error detection and recovery
precedure and a robust command queuing implementation.

Finally, I strongly agree with the sentiment of getting the first version
"out the door".
The issues surrounding CRC's and error recovery need to be put to reset
asap.

David Peterson
Lead Architect - Standards Development
Cisco Systems - SRBU
6450 Wedgwood Road
Maple Grove, MN 55311
Office: 763-398-1007
Cell: 612-802-3299
Email: dap@cisco.com