The present invention generally relates to the field of electronic devices, and particularly to device diagnosis and storage of device performance data.
Failure of hardware or software systems due to device operation may cause a loss of essential data. One method used to avoid this problem is S.M.A.R.T. technology. S.M.A.R.T. is an acronym that stands for self-monitoring analysis reporting tool. S.M.A.R.T. monitors performance indicators and is intended to provide users with an early warning of impending device failure. However, in many instances device failure is sudden and may occur with little or no advanced warning. This may be particularly harmful in storage devices, where failure may occur before the user has the opportunity to save information to other media. One reason for the lack of sufficient warning time is that S.M.A.R.T. reports few of the performance indicators, less than twenty (20), of what a device is able to report, which may be more than 150 in the case of a storage device. For example, additional performance indicators are recorded in storage devices on the media, in most cases in a vendor specific area. Typically, only the vendor may access and analyze the data contained in this area using special vendor unique commands and diagnostic tools. If device failure was caused by mechanical or chipset failure, the data stored in the vendor unique area may be lost or only partially recovered by the manufacturer. For instance, in the case of chipsets or spindle motor failures in a hard drive, swapping a damaged printed circuit board or replacing a damaged spindle may help to recover the data. But, in the case of head damage, scratches or anything related to the voice coil, head, or media, the performance indicators could be lost. The loss of the performance indicators makes it very difficult to determine the root cause of device failure. Other traditional methods of determining the cause of failure, such as a failure analysis, require an extended period of time and effort before a report is issued. For example, in some cases, performing a failure analysis requires opening the device assembly in a xe2x80x9cclean roomxe2x80x9d to prevent contamination of the media.
Repair of the device may be greatly simplified by knowing the precise cause of the device failure. For instance, the user may know which part of the device to repair, and whether the device can be repaired. Additionally, performance data is valuable even if it was not possible to repair the device. By making it easy to access this data even after device failure, a detailed record of what caused the device to fail can be obtained. The scope and value of quality control is increased by having a detailed picture of why the devices failed. This would allow a greater sampling to be taken to determine the cause of failure of the devices.
Furthermore, disk drive vendors are challenged today by system manufacturers to optimize the drive for every operating system to load its content faster, to retrieve or pre-fetch the data even faster and most importantly to win magazine reviews. To optimize a drive for all of the above, vendors often have difficulty accommodating the changes required by differing operating systems under a single firmware or a single cache algorithm so as to eliminate disk seeking operations and the overhead due to rotational latency delays. Therefore, a vendor may wish to have different firmware modules optimized for different operating systems.
For the forgoing reasons, there is a need for a data recorder that may be used to store device performance data that is easily accessed after device failure. Additionally, there is a need for a data recorder that stores software tools to repair a damaged operating system or device driver software program and to optimize a device for a specific operating system.
The present invention addresses such problems by connecting a data recorder to the device. The data recorder includes a memory device that stores performance data. Performance data may include data traditionally stored in the vendor unique area on a hard disk drive. In this way, the data recorder is accessible after device failure, thereby making it easier to determine the cause of failure of the device.
The data recorder may be disposed on the device so that it may be removed and examined. Further, information obtained may then influence future designs of the device so that past failures may be rectified. For instance, it may be determined that a certain component of the device is prone to failure. That portion of the device may then be improved, such as by redesigning the component or deriving the part from another manufacturer.
Additionally, a data recorder may store software tools to repair damaged operating systems, such as device driver software. The operating system may become corrupted thereby denying the user access even without a mechanical or printed circuit board failure. The operating system may be repaired by having a data recorder control the restoration of the operating system. By having an image of the original download saved, such as the operating system, the data recorder may initiate a repair program. The repair program may be initiated by simply inserting a floppy disk or similar removable media in the information handling system to replace the lost data sector by sector as it was shipped from the system manufacturer or replace the lost data in an updated version by utilizing the performance data contained in a data recorder. The repair program may also be initiated through vendor unique commands, such as hidden copy and restore. For example, the data recorder stores information regarding the latest operating system and device drivers used by the device or information handling system so that this data is restored by the data recorder should the original version become corrupted.
Furthermore, the data recorder may optimize device performance by specifying a particular module to load for a corresponding operating system. To determine which module to load when power is applied to the device, the data recorder and its program utilities pinpoint which operating system is utilized and then indicate which module to load based on the indicated operating system.
The present invention is directed to a system and method for storage of device performance data. In an exemplary embodiment, a data recorder includes a memory device connected to at least one device for storing performance data obtained from the device wherein the memory device is accessible after failure of the device. In an additional embodiment of the present invention, a system and method for optimizing device performance includes determining an operating system type, saving the operating system type in a data recorder and loading a firmware module based on the saved type. In a further exemplary embodiment of the present invention, a system and method for preventing loss of device performance data includes obtaining performance data from a device and storing the performance data on a data recorder wherein the data recorder is accessible after failure of the device. It may be desirable to store performance data to the data recorder so as not to affect the operation of the device. In yet another exemplary embodiment, a system and method for restoring a corrupted data structure with device self-stored repair tools includes determining whether a data structure of an operating system is corrupted and restoring the data structure from data recorder data if the data structure is corrupted.
It is to be understood that both the forgoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention and together with the general description, serve to explain the principles of the invention.
USPTO Backgrounds
USPTO Backgrounds