A. Pass is indicated by completion of the testing script without error.
B. Fail is indicated by failure to complete any function within the testing script.
C. RL 0 is typically a full pass of Write and a full pass of Read.
A. The tester’s Operating System (Linux OS) is unable to mount the drive in the allowed time.
B. HDD may or may not post ready. The failure of the OS to mount the drive or it’s not mounted in a reasonable period
(Note: Not mounted in a reasonable time is an indication of defective HDD. (Clients have observed a number of these HDD’s).
This is the same issue, but on the secondary port of a SAS drive.
A. ORS repairs during every pass. It is possible that a second run on a failure drive will repair and result in a pass drive. Further enhancements to ORS will address this issue. However, there will always be a small number of unstable HDD which display different test results with multiple passes.
B. Some HDD are unstable or have continuing defect generation. It is possible that a pass of ORS will repair such a drive and then it will fail on a subsequent pass. This is not typical but does occur. Typically, an unstable HDD will not pass RL 0.
C. The reported Failure Code is not always consistent. For example: Write failure TST-003 on the first pass will fail Read TST-005 on a second pass.
D. After installation of TEA 1.0.0 only failures MSG-xxx, TEF-xxx and HEF-xxx are suggested for retesting.
ORS Application does not pass a HDD which fails any test function or script.
A. The internal time out setting (TST-009) is disabled in TES 1.0.0; thus, the number of TST-009 failures are reduced and possibly eliminated.
B. Currently retest all TST-009 failures.
C. TST-009 failures are a result of an internal time out setting in the ORS Application.
D. The internal time out setting was to catch and failure HDD failures early in test versus occupying tester for hours before failing.
A. Currently retest all SCR-021 failures.
B. If fails second time for SCR-021 or any other failure code after SCR-021, the HDD is a confirmed failure.
A. Retest all MSG-xxx.
B. MSG-xxx is a bug in the ORS Application and being resolved in next release.
A. Retest all HEF-xxx.
B. If fails second time for any failure mode HDD is a confirmed failure.
A. All confirmed media defects are reallocated.
B. Future releases will do a low-level format of the drive and remove all reallocated defects.
A. A Write failure has a number of possible causes
1. Bad write element in a head.
2. Bad read element in a head which prevents servo tracking.
3. Damaged servo sectors on the media preventing servo on track.
4. Electronic failure.
5. Large damage area on media from either contamination or head crash.
B. Write Failures on ORS typically require internal HDD repairs.
C. It is possible to recover some small percentage of TST-003 failures with second pass of ORS.
A. A Read Failure has a number of possible causes
1. Bad read element in a head.
2. Contamination or damage of the head or of the media.
3. Electronic failure.
4. Bad write.
B. It is possible to recover some small percentage of TST-005 failures with a second pass of ORS.
A. Yes, these errors are reallocated and HDD will subsequently pass.
B. Future releases will do a low-level format of the drive and remove all reallocated defects.
All the user data on each HDD are not accessed or transmit in any ways in our system by design, so there is no transmission or leaking issue on the network. We ensure this design by these mechanisms:
1. System reads the drive information – brand, model, capacity, and other drive service data.
2. System starts with full surface overwriting – all useable data area will be erased.
3. System then starts full surface read verification.
4. At no time, user data on the drive was read in the system or transmit over the network.
5. The TM module (the one loaded with the drives) are in internal network of the ORS system, it is not connected to external network and the IP addresses we used are not routable, i.e., not possible to be accessed from external network.
6. All system connected to our external network are through SRMS’s VPN and only SRMS’s authorized system with unique signature for the site could be connected. The VPN authorization could not be done over network, it will require physical configuration on the SRMS VPN firewall device in a secured location.
No user data was ever accessed by our TM modules, so the data was not even available anywhere in the system – not in RAM, local storage or local network, not to mention the external network.
SRMS could provide an offline wiping solution to wipe the data first before customers put drives into ORS. The wiping solution will be a system without network connection, so this will automatically eliminate the above concerns.
This could be verified easily by the clients or any 3rd party certification party. The repaired or wiped drives are fully erased without any data left.
Since the whole usable drive surface has been overwritten with the new data, there is no way to recover the data with the modern hard drive technology.
