|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Tape drives and iSCSIDon'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
Home Last updated: Tue Sep 04 01:05:06 2001 6315 messages in chronological order |