Method and apparatus for logically rejecting previously recorded track residue from magnetic media

Abstract

A method for logically rejecting previously recorded track residue from magnetic media is presented. A session ID unique to a given recording session is encoded into track packet error check and error correction codes but is not itself actually written to tape. During a data recovery session, a reference session ID for the original recording session is acquired by reconstructing the packet session ID from the first few track packets and verifying that a predetermined number of consecutive track packets have identical packet session IDs. Once the reference packet session ID is acquired, it is preloaded into error detection and correction hardware. When a residue track encoded with a previously recorded session ID is recovered by the tape drive track packet detection circuitry, it is inherently rejected because the error detection and correction hardware detects an error and it is therefore never allowed into the data buffer.

Description

FIELD OF THE INVENTION

The present invention pertains generally to data recording and recovery methods, and more particularly to a method for logically rejecting previously recorded track residue from magnetic media.

BACKGROUND OF THE INVENTION

Tape storage technology is routinely used for routine system back up and long-term data archiving. In the ongoing goal to minimize the cost-to-capacity ratio while still maintaining data integrity, ways are always looked at to reduce drive costs. One way to reduce drive costs is to reduce the costs of the components of the recording device. For example, in the tape drive industry, many tape drive architectures employ an erase head for erasing a magnetic tape before recording data to it. In prior art architectures, this is necessary because portions of tracks written onto the tape that are not precisely overwritten may be unintentionally detected by the read head during a later read session. These previously written portions of tracks, herein termed “residue”, are problematic because although they are not intended to be read, they are still detected by the read logic.

Accordingly, a need exists for a method for logically rejecting previously recorded track residue during a read session to prevent data that is not intended to be read from being included in the recovered data sent to the host system.

U.S. Pat. No. 4,910,736 to Tonaka et al. describes the addition of an identification (ID) code and an error check code to each block of the data that makes up a track. The ID code is used to indicate that the block of data belongs to a particular recording session. The error check code is used for error checking of the block of data. In the absence of an error, the original ID code is reconstructed and compared to a reference ID code obtained from a reference ID code setting circuit. If the reconstructed ID code does not match the reference ID code, the block of data is logically rejected as not intended to be read. This approach for logically rejecting residue data reconstructs the original ID code for each block of data recovered from the medium. In addition, a separate reference ID code setting circuit is employed to obtain the reference ID code.

In the interest of reducing the amount of time it takes to determine whether a given block of data belongs to the same recording session as identified by the reference ID code, it would be desirable to have a method for logically rejecting recovered data without having to reconstruct the original ID code for every block of data. In addition, it would be desirable to reduce the amount of hardware, and thus the amount of valuable chip space required to implement the method.

SUMMARY OF THE INVENTION

The present invention is a novel method for logically rejecting previously recorded track residue from magnetic media by encoding an identical recording session ID code into the track packet error correction code of every track packet recorded during a single write session. Error correction is performed on the first few track packets to acquire a reference session ID. The reference session ID is used to preload the ECC syndrome and CRC generators prior to processing each recovered packet to determine whether the recovered packet is valid for the current session. Those packets that are recovered but which have a session ID that does not match the acquired session ID are inherently rejected as unintended to be read because the ECC syndromes and CRC generators will indicate an error. As a result, there is no need to actually reconstruct the packet's original session ID. Accordingly, the invention provides an efficient way of determining whether a recovered track packet was recorded during the recording session identified by the acquired session ID.

In accordance with the invention, a session ID unique to a given recording session is generated at the beginning of the recording session and encoded into an error correction code redundancy field of a track packet. When the track packet is written to tape, the session ID itself is not actually sent to the tape, thereby reducing the amount of overhead data required for each track and increasing the actual data-capacity-to-overhead ratio of the media. During a data recovery session, the session ID encoded in the ECC redundancy field of the track packet is acquired by assuming that the entire contents of the first few track packets are good and performing packet error correction on a number of packets to reconstruct the current session ID. If several consecutively reconstructed session IDs match, the session ID is considered acquired. Once the session ID is acquired, it is preloaded into the CRC/ECC error detection and correction hardware prior to processing each subsequent recovered track packet. Only recovered track packets that are encoded with the acquired session ID are considered good and therefore allowed to be sent to the data buffer; packets that are encoded with a different session ID other than the acquired session ID are rejected by the CRC/ECC error detection and correction hardware.

Accordingly, the technique of the invention eliminates the need for a costly erase head yet requires no additional track packet overhead to be recorded onto the magnetic media. In addition, track packet rejection is more efficient since once the reference session ID is acquired, the original session ID need not be reconstructed for every recovered track packet. Finally, the same error correction hardware used to correct packet errors is used to acquire the session ID, thereby eliminating the requirement for separate hardware to do each function.

BRIEF DESCRIPTION OF THE DRAWING

The invention will be better understood from a reading of the following detailed description taken in conjunction with the drawing in which like reference designators are used to designate like elements, and in which:

FIG. 1 ( a ) is a side view of a portion of a magnetic tape illustrating a first track pattern that results in a previously recorded track residue zone;

FIG. 1 ( b ) is a side view of a portion of a magnetic tape illustrating a second track pattern that results in a previously recorded track residue zone;

FIG. 2 ( a ) is a flowchart illustrating a method in accordance with the invention for generating and encoding a session ID in a track packet;

FIG. 2 ( b ) is a diagram illustrating the construction of a track packet in accordance with the method of FIG. 2 ( a );

FIG. 3 ( a ) is a flowchart illustrating one embodiment of a method in accordance with the invention for acquiring the current session ID at the start of a data recovery session when the tape drive is in a normal read mode;

FIG. 3 ( b ) is a diagram illustrating the construction of a track packet in accordance with the method of FIG. 3 ( a );

FIG. 4 ( a ) is a flowchart of one embodiment of a high-speed search session ID acquisition method;

FIG. 4 ( b ) is a diagram illustrating the high-speed search session ID acquisition process;

FIG. 5 ( a ) is a flowchart of one embodiment of a method in accordance with the invention for logically rejecting residue data during a data recovery session; and

FIG. 5 ( b ) is a diagram illustrating the process of FIG. 5 ( a ).

DETAILED DESCRIPTION

A method and apparatus for logically rejecting previously recorded track residue during a read session of data recorded over the previously recorded tracks is described in detail hereinafter.

In the recording of data onto a magnetic medium that contains previously recorded tracks, previously recorded track residue can result unless the portion of the media on which the new data is recorded is erased. Previously recorded track residue can result for a number of reasons, including recording/recovery device or media interchange issues, track pitch discontinuity, variable speed recording capability, track curvature, or head clogs.

FIG. 1 ( a ) is a side view of a portion of a magnetic tape 2 illustrating previously recorded track residue zones 6 resulting from interchange between recording/recovery devices or media. More recently recorded tracks 4 overwrite most but not all of any previously recorded tracks. However, when magnetic media is recorded on one device and then re-recorded to on a different device, a slight difference in recording head alignment prevents the previously recorded tracks from being precisely overwritten and thus results in residue zones, for example those shown at 6 on magnetic tape 2 .

FIG. 1 ( b ) illustrates a second track pattern that results in a previously recorded track residue zone. In this embodiment, residue zone 6 results from variable recording speeds. In drives that support variable speed recording, a speed change results in an angular gap between tracks 4 a recorded at one speed and tracks 4 b recorded at another speed. When a recording speed change occurs over a portion of previously recorded media, previously recorded track residue zones 6 result in the angular gap between tracks 4 a and 4 b.

Referring back to FIG. 1 ( a ), data is formatted into track packets 8 before being recorded to the magnetic media 2 . Multiple track packets 8 exist on each track 4 . Each track packet 8 includes framing information 10 used by the read logic of the recording/recovery device for detecting the leading edge of a packet 8 , a local packet address field 12 used by the read logic in constructing the global address of the data, a data field 14 for storing user data if the track packet is a data field, a CRC field 16 used by the read logic to detect an error in data field 14 , and an error correction code ECC field 18 used in conjunction with the CRC field 16 to detect and correct errors across packet 8 . As described hereinafter, the session ID is encoded in the CRC field 16 and ECC field 18 and may be recovered via error correction techniques. However, the session ID itself is not separately stored in the packet on the media.

FIG. 2 ( a ) is a flowchart illustrating a method in accordance with the invention for generating and encoding a session ID in a track packet 8 . FIG. 2 ( b ) is a diagram illustrating the construction of a track packet 8 in accordance with the method of FIG. 2 ( a ). At the beginning of a recording session, a session ID 52 is generated by a session ID generator 50 and assigned to the current recording session in step 202 . The tape drive firmware keeps track of the last session ID used as part of its logical formatting on tape and always assigns the next one in sequence when a new write session begins. This is accomplished by storing system data containing the last used session ID in the end-of-data (EOD) area and/or the system partition area on the tape that contains system data used by the drive. Thus, when data is appended to previously recorded data during a new recording session, the tape drive firmware extracts the last used session ID from the system data contained in the EOD area, and increments it by one to generate the current session ID. The session ID remains constant during the entirety of the recording session.

During a recording session, user data is partitioned into data packets 15 , which include data field 14 and local packet address field 12 . Data packets are formatted into track packets 8 before being recorded to a magnetic media. In step 204 , a CRC generator 54 generates a CRC 56 across the assigned session ID 52 and the data packet 15 . The CRC 56 is appended as CRC field 16 to the data packet 15 . In step 206 , an ECC generator 58 generates an error correction code (ECC) 60 over the assigned session ID 52 , local packet address field 12 , data field 14 , and CRC field. The ECC 58 is appended as ECC field 18 to track packet 8 . Framing information 10 is added ahead of track packet 8 , which is then modulated and sent to the write channel of the recording device to be recorded onto the magnetic media in step 208 .

FIG. 3 ( a ) is a flowchart illustrating one embodiment of a method in accordance with the invention for acquiring the current session ID at the start of a data recovery session when the tape drive is in a normal read mode (i.e., when the tape is moving at normal read speed). FIG. 3 ( b ) is a diagram illustrating the construction of a track packet in accordance with the method of FIG. 3 ( a ).

During the acquisiton of a session ID, all data packets recovered are assumed to contain no errors. The method 300 begins with a step 302 in which a possible session ID 76 , a total packet count 80 , and a good packet count 88 are each cleared. In a step 304 , a track packet 8 is recovered from tape and copied (minus the framing information 10 ) into a temporary buffer location 72 , and the total packet count is incremented. In a step 306 , a packet session ID 20 associated with the track packet 8 is cleared (i.e., reset to all zeros) in preparation for error correction by packet error correction logic 74 . In step 308 , error correction is performed on track packet 8 by error correction logic 74 . This step corrects the erased packet session ID 20 using the contents of the track packet 8 located in temporary buffer location 72 , which are assumed to be correct, to reconstruct the original packet session ID of recovered track packet 8 . The reconstructed packet session ID is captured as a possible session ID in step 310 . CRC and ECC generators 82 and 84 perform error detection on the corrected track packet 8 in step 312 . If an error is detected, as determined in step 314 , the possible session ID and track packet are rejected, and the process repeats beginning at step 302 . If no errors are detected in the track packet 8 , the good packet count is incremented in step 316 . The reconstructed packet session ID is then compared against the possible session ID 76 in step 318 . After the first pass, a mismatch will occur since the possible session ID 76 is cleared at the beginning of the acquisition process. Accordingly, the reconstructed packet session ID is captured as the possible session ID 76 in step 320 . At the point in the method reach in step 320 , a single good possible session ID has been detected. In accordance with the illustrative embodiment, the method is always looking for two identical session IDs in a row as a criteria for considering a reconstructed session ID as a real possible session ID. Accordingly, in step 320 the good packet count and total packet count are set to a count value of one if they are not already set to one. Steps 304 through 318 are repeated to attempt to capture two identical reconstructed packet session IDs for two contiguous track packets 8 .

Once two contiguous track packets 8 are detected to have been recorded during the same recording session (by having identical packet session ID's), subsequent recovered track packets 8 are monitored for a predetermined number of total packets to determine the ratio of good packets to rejected packets. This stage of the acquisition process begins in step 318 if the reconstructed session ID matches the possible session ID for a second or greater consecutive good track packet with an identical reconstructed session ID. For every subsequent error-free track packet with an identical reconstructed packet ID up to a predetermined number of total subsequent tracks, steps 304 through 316 are repeated. Then in step 322 , a determination is made as to whether the predetermined total number of consecutive packets have been processed. If not, steps 304 through 322 are repeated. Once the predetermined total number of consecutive packets have been processed, the ratio of good packets to total processed packets, based on the value of the good packet count 88 , is determined in step 324 . If the value of good packet count 88 is not acceptable, for example by comparing it to a minimum threshold level, the possible session ID is discarded and the entire acquisition process beginning with step 302 is repeated. If, however, the value of good packet count 88 is acceptable, the session ID is considered acquired, and the possible session ID 76 is adopted as the acquired session ID 78 in step 326 .

In the illustrative embodiment, the session ID acquisition logic 90 waits to process two identical session ID 76 values in a row during a reconstruction portion of the acquisition process, determines whether an acceptable number of good packets are detected during a predetermined number of total subsequent recovered track packets during a verification portion of the acquisition process, and adopts the session ID 76 as the acquired session ID 78 if an acceptable number of good packets are detected during this period. It will be appreciated by those skilled in the art that the number of required identical reconstructed packet session ID's detected during the reconstruction portion of the acquisition process, and the number of required good packets recovered during the verification portion of the acquisition process, are adjustable.

In a preferred embodiment, the session ID may also be acquired when the drive is operating in a high-speed search mode—that is, the tape is being transported at greater than normal read speed and data is not actually being read from the tape. FIG. 4 ( a ) is a flowchart of one embodiment of a high-speed search session ID acquisition method 400 . FIG. 4 ( b ) is a diagram illustrating the high-speed search session ID acquisition process. According to the preferred embodiment for high-speed search mode session ID acquisition, session ID acquisition logic 90 monitors only control packets recovered from tape at high speed. Each control packet 40 includes a control packet address 30 , a control packet body 32 that contains control information including the session ID 34 that matches that of the recording session when the control packet was recorded, a packet CRC field 16 and a packet ECC field 18 . Packet detection logic 70 detects control packets 40 and places them into a temporary packet buffer location 72 . Packet correction logic 74 reconstructs the packet session ID 34 for each recovered control packet 40 . Session ID acquisition logic 90 processes the recovered control packets 40 and associated reconstructed packet session ID's 32 to acquire the original session ID 78 of a particular portion of tape.

In the preferred embodiment, a first control packet is recovered and its associated packet session ID is reconstructed in a step 402 . The reconstructed packet session ID is maintained as a possible session ID 76 . In a step 404 , a second control packet is recovered and its associated packet session ID is reconstructed. The second reconstructed packet session ID is compared to the possible session ID 76 in a step 406 . If the two session ID's do not match, the process starts over again with step 402 . If the two session ID's do match, however, the session ID acquisition logic 90 waits a predetermined (preferably programmable) number of drum revolutions in step 408 . A third control packet 40 is recovered in step 410 and its associated packet session ID is reconstructed. The third packet session ID is compared to the possible session ID in step 412 . If the third packet session ID does not match the possible session ID, the process starts over again with step 402 . If the third session ID does match the possible session ID, a fourth control packet 40 is recovered in step 414 and its associated packet session ID is reconstructed. The fourth packet session ID is compared to the possible session ID in step 416 . If the third packet session ID does not match the possible session ID, the process starts over again with step 402 . If the fourth session ID does match the possible session ID, the possible session ID is adopted as the acquired session ID in step 418 and the method 400 is complete. Once a session ID is acquired, it is used until a programmable number of control packets have failed to be read. When this condition occurs, the logic repeats the session ID acquisition.

In the preferred embodiment, the tape drive has the capability for allowing a user to set the session ID, thereby overriding an automatically acquired session ID.

FIG. 5 ( a ) is a flowchart of one embodiment 500 of a method in accordance with the invention for logically rejecting residue data during a data recovery session. The method 500 begins by first acquiring a reference session ID in step 502 . The reference session ID is acquired, for example, using the method of FIG. 3 ( a ) or 4 ( a ). In a step 504 , the reference session ID is preloaded into the CRC and ECC syndrome generators 82 and 84 . A track packet 8 is recovered from tape during a step 506 . In step 508 , the track packet 8 is simultaneously copied into a temporary packet buffer location 72 and sent to the CRC and ECC syndrome generators 82 and 84 to detect any errors in the local packet address field 12 or data field 14 of the packet. If an error is detected in the address or data field of the packet, it is corrected by packet correction logic 74 in step 510 . Error correction is performed on the corrected packet in step 512 in case the packet was miscorrected due to being encoded with a residue session ID. If an error is detected, the packet is discarded in step 516 and not sent to the data buffer because it would have been corrected correctly by the packet correction logic 74 if its original packet session ID as encoded in the packet CRC field 16 and packet ECC field 18 matched that of the reference session ID. Accordingly, the packet is inherently rejected as unintended to be read and is not copied from the temporary packet buffer location 72 for further processing. However, if the CRC and ECC syndrome generators 82 and 84 do not initially detect any errors in step 508 , or after the packet has been corrected in step 512 , the packet is considered good and sent to the data buffer in step 514 . Steps 506 through 516 are repeated for each subsequent recovered track packet 8 of the current data recovery session.

FIG. 5 ( b ) is a diagram illustrating the process of FIG. 5 ( a ). During a data recovery session, once the session ID for the current session is acquired, data packets 8 and control packets 40 are checked by packet detection logic 70 while they are written into temporary packet buffer location 72 . Packet detection logic 70 notifies the packet correction logic 74 when a packet 8 is available in the temporary buffer location 72 . Packet correction logic 74 corrects any error in the address field 12 or data field 14 of packets 8 that fail checks by the CRC generator 82 and Reed-Solomon ECC generator 84 that were performed by the packet detection logic 70 . If error correction was performed on a packet 8 , CRC and ECC error detection is performed on the corrected packet by CRC generator 82 and ECC generator 84 as it is being sent to its location in the data buffer 96 in case the packet was miscorrected due to being encoded with a residue session ID. If the packet 8 was miscorrected, the error detection circuitry 82 and 84 will detect this condition and the miscorrected packet 8 is discarded.

It will be appreciated by those skilled in the art that the present invention provides several advantages over the prior art. First, the need for a costly erase head and associated control hardware is eliminated. Secondly, track packet rejection is more efficient since, once the reference session ID is acquired at the start of a data recovery session, the packet session ID need not be reconstructed for every subsequent recovered track packet. Finally, the same error detection hardware used to detect packet errors and same error correction hardware used to correct packet errors is used to acquire the session ID, thereby eliminating the requirement for separate session ID acquisition hardware.

Although the invention has been described in terms of the illustrative embodiments, it will be appreciated by those skilled in the art that various changes and modifications may be made to the illustrative embodiments without departing from the spirit or scope of the invention. It is intended that the scope of the invention not be limited in any way to the illustrative embodiment shown and described but that the invention be limited only by the claims appended hereto.

Claims

1. A method for logically rejecting previously recorded recovered track packets from a magnetic media, comprising:acquiring a reference session identifier (ID); recovering a track packet from said magnetic media, said track packet comprising a data field, an error detection and or correction (detection/correction) field, and a packet session identifier (ID) encoded in said error detection/correction field; generating an error code over said data field using said error detection/correction field and said acquired reference session ID without reconstructing said packet session ID encoded in said error detection/correction field, said error code indicative of the presence or absence of an error in said data packet; and if said error code indicates no error in said track packet, considering said data packet as belonging to a session identified by said reference session identifier.

2. A method in accordance with claim 1, comprising:repeating said recovering step through said considering step without reacquiring said reference session ID.

3. A method in accordance with claim 1, wherein:said error detection/correcbon field comprises a cyclical redundancy code (CRC) with said packet session ID encoded in said CRC.

4. A method in accordance with claim 1, wherein:said error detection/correction field comprises: a cyclical redundancy code (CRC) with said packet session ID encoded in said CRC; and an error correction code (ECC) with said packet session ID encoded in said ECC.

5. A method in accordance with claim 1, wherein:said error detection/correction field comprises an error correction code (ECC) with said packet session ID encoded in said ECC.

6. A method in accordance with claim 1, wherein:said error detection/correction field comprises a cyclical redundancy code (CRC) with said packet session ID encoded in said CRC; and said error code generator comprises a cyclical redundancy code (CRC) generator which receives said reference session ID and said encoded CRC code.

7. A method in accordance with claim 1, said acquiring step comprising:recovering a predetermined number of track packets that have identical packet session ID's; and adopting said identical packet session ID as said reference session ID.

8. A method in accordance with claim 7, comprising;recovering a first track packet; reconstructing said packet session ID of said first track packet; holding said reconstructed packet session ID of said first track packet as a possible session ID; recovering a next track packet; reconstructing said packet session ID of said next track packet; comparing said reconstructed packet session ID of said next track packet to said possible session ID; repeating said first track packet recovery step through said comparison step if said reconstructed packet session ID of said next track packet does not match said possible session ID; determining whether a predetermined number of packets have been recovered since said first track packet was recovered; repeating said next track packet recovering step through said determining step if said predetermined number of packets have not yet been recovered; and adopting said possible session ID as said acquired session ID if said predetermined number of packets have not yet been recovered.

9. A method for acquiring a session identifier from a magnetic media, said method comprising the steps of:recovering a first track packet from said magnetic media, said first track packet comprising a first data field, a first error correction field, and a first packet session identifier (ID) encoded in said first error correction field; performing error correction on said first track packet to reconstruct said first packet session ID encoded in said first error correction field; recovering a subsequent track packet from said magnetic media, said subsequent track packet comprising a subsequent data field, a subsequent error correction field, and a subsequent packet session ID encoded in said subsequent error correction field; performing error detection on said subsequent track packet using said reconstructed first packet session ID; repeating said first recovering step through said second performing step if an error is detected in said subsequent track packet; and repeating said second recovering step through said second repeating step until a a predetermined number of subsequent recovered track packets are detected as error-free.

10. An apparatus for logically rejecting previously recorded recovered track packets from a magnetic media, comprising:a packet detection circuit which detects a track packet from said magnetic media, said track packet comprising a data field, an error detection and or correction (detection/correction) field, and a packet session identifier (ID) encoded in said error detection/correction field; an error code generator which receives a reference session identifier (ID) and said track packet detected by said packet detection circuit and generates an error code over said data field using said error detection/correction field and said acquired reference session ID without reconstructing said packet session ID encoded in said error detection correction field, said error code indicative of the presence or absence of an error in said data packet; and packet error detection circuitry that monitors said error code and passes said data field of said track packet to a data buffer if said error code indicates no error in said track packet.

11. A method in accordance with claim 10, wherein:said error detection/correction field comprises an error correction code (ECC) with said packet session ID encoded in said ECC; and said error code generator comprises an error correction code (ECC) generator which receives said reference session ID and said encoded ECC code.

12. A method in accordance with claim 10, wherein:said error detection correction field comprises a cyclical redundancy code (CRC) with said packet session ID encoded in said CRC and an error correction code (ECC) with said packet session ID encoded in said ECC; and said error code generator comprises a cyclical redundancy code (CRC) generator which receives said reference session ID and said encoded CRC code and an error correction code (ECC) generator which receives said reference session ID and said encoded ECC code.