Hard disk failure handling method and computing device

Abstract

Embodiments of the present application relate to a hard disk fault processing method and a computing device. The method comprises: in response to detecting that a first hard disk in a storage system has a faulty head, obtaining a first logical address range corresponding to the faulty head; determining a target storage stripe unit affected by the faulty head based on the first logical address range; performing data reconstruction on the target storage stripe unit, and writing the reconstructed data into a redundant storage resource of the storage system. In this way, the problem of high hard disk failure rate and long reconstruction time caused by triggering full-disk replacement and full-disk reconstruction due to single-head failure in the related art can be solved, and the reliability of the storage system can be maintained while significantly reducing the operation and maintenance cost and improving the resource utilization.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a hard disk failure handling method and a computing device. Background Technology

[0002] With the continuous growth in data storage demands, the storage density of hard disk drives (HDDs) has been steadily increasing. In recent years, hard drives employing new technologies such as heat-assisted magnetic recording (HAMR) have emerged, achieving higher single-platter capacity by integrating precision components such as lasers into the read / write heads. However, the more complex structure of these new heads leads to a higher failure rate during their operational cycle compared to traditional heads.

[0003] In storage systems employing Redundant Arrays of Independent Disks (RAID) technology, RAID controllers typically handle failures on an entire physical hard drive as the smallest management unit. When a head on a hard drive fails, the technology classifies the entire drive as faulty and isolates it from the RAID group, triggering a full disk reconstruction of all data blocks. This coarse-grained management strategy fails to utilize the independent operation of the hard drive's internal heads, artificially inflating the overall hard drive failure rate and leading to a lengthy reconstruction process for large-capacity hard drives, increasing the risk of data loss. Summary of the Invention

[0004] This application provides a hard disk failure handling method and computing device, which can significantly reduce operation and maintenance costs and improve resource utilization while maintaining the reliability of the storage system.

[0005] According to a first aspect of the embodiments of this application, a hard disk failure handling method is provided, the method comprising:

[0006] In response to the detection of a faulty read / write head on the first hard drive in the storage system, the first logical address range corresponding to the faulty read / write head is obtained; Based on the first logical address range, determine the target memory stripe cell affected by the faulty head; The target storage stripe cell is reconstructed, and the reconstructed data is written to the redundant storage resources of the storage system.

[0007] This embodiment addresses the issue of high hard drive failure rates and long reconstruction times caused by single-head failures triggering full disk replacement and reconstruction. It improves storage system reliability by maintaining overall system reliability while significantly reducing maintenance costs and improving resource utilization. This approach shifts the focus of fault management and data reconstruction from the entire hard drive to individual heads. By identifying and obtaining the specific logical address range of the faulty head, the affected storage stripe cells are located. Only these limited stripe cells undergo partial data reconstruction, and redundant resources are stored.

[0008] In one possible implementation, in response to detecting a faulty read / write head on the first hard disk in the storage system, the following steps are included: Obtain the first response message from the first hard drive. The first response message contains an error code indicating a faulty read / write head.

[0009] This embodiment introduces and defines dedicated error codes to indicate head failures, establishing a communication mechanism between the hard drive and the RAID controller regarding head-level fault status. This not only enables rapid and accurate identification of the root cause of the fault but also provides a decision-making basis for subsequent isolation and reconstruction at the logical address range granularity, ensuring that the system can evolve from the traditional disk-level management mode to a fine-grained head-level management mode.

[0010] In one possible implementation, obtaining the first logical address range corresponding to the faulty head includes: Send a head information query command to the first hard drive; Receive the second response information sent by the first hard disk, the second response information containing description information of the first logical address range.

[0011] This embodiment, through a proactive command-response interaction mechanism, enables a precise description of the impact range of a faulty read / write head. The RAID controller can obtain precise location information of the fault within the hard drive's logical space, rather than a general fault signal. This allows subsequent isolation and reconstruction operations to be strictly limited to the affected, potentially discontinuous, specific LBA intervals, thereby ensuring the accuracy of localized processing and preventing healthy areas from being mistakenly isolated.

[0012] In one possible implementation, the description information of the first logical address range includes: the number of logical address segments, and the starting logical block address and ending logical block address of each logical address segment.

[0013] This embodiment explicitly quantifies the jurisdiction of the read / write head into a logical address range defined by one or more start and end LBA pairs. This provides the RAID controller with precise fault location information. This allows the system to perform isolation and reconstruction operations with minimal granularity, avoiding accidental isolation or redundant reconstruction of healthy storage areas.

[0014] In one possible implementation, after writing the reconstructed data to redundant storage resources of the storage system, the method further includes: When receiving an access request to the first hard disk, determine whether the target logical address sought by the access request is within the range of the first logical address; When the target logical address is within the first logical address range, the access request is redirected to the corresponding address of the redundant storage resource for processing.

[0015] This embodiment achieves dynamic and lossless isolation of access to faulty areas through the aforementioned real-time judgment and redirection mechanism. It ensures that application access requests to the area where the faulty head is located are processed seamlessly and correctly, while blocking direct access to physically damaged areas. This maintains the business continuity of the storage system while maximizing the availability and performance of healthy storage media within the faulty hard drive.

[0016] In one possible implementation, the method further includes: When the target logical address of the access request is within the range of the second logical address, the access request is sent to the first hard disk.

[0017] This embodiment clarifies the access path for healthy hard disk regions, which, together with the isolation and redirection mechanism for faulty regions, constitutes a complete I / O scheduling strategy. Through this strategy, the system can dynamically and accurately distinguish the access target of each I / O request. For faulty regions, data accessibility is ensured through redirection; for healthy regions, the original direct access path is maintained. This ensures that while tolerating local head failures, performance overhead is minimized, and the overall I / O processing efficiency and low latency of the system are maintained, achieving a balance between fault tolerance and performance optimization.

[0018] In one possible implementation, data reconstruction of the target storage stripe cell includes: Read all data blocks in the target storage stripe cell except for the data block corresponding to the faulty head; Based on a preset redundancy algorithm, the reconstructed data of the data block corresponding to the faulty head is calculated using other data blocks.

[0019] This embodiment ensures accurate recovery of faulty data by explicitly decomposing the reconstruction process into data collection and verification calculations. It can strictly limit the consumption of computing resources and I / O bandwidth to the few necessary stripes affected by the fault, thereby achieving the goal of restoring data availability with minimal system overhead. This is a key technical implementation path to significantly shorten reconstruction time and reduce system load.

[0020] In one possible implementation, the method further includes: In response to a head failure in the second hard drive of the storage system, determine the third logical address range affected by the failed head in the second hard drive; If the storage stripe unit corresponding to the third logical address range belongs to the same stripe as any target storage stripe unit that has completed data reconstruction and is stored in redundant storage resources, a replacement alarm for the second hard drive is triggered.

[0021] This embodiment effectively identifies high-risk scenarios where multiple partial failures cause too many data blocks within the same RAID stripe to concentrate on a single hot spare disk, effectively rendering redundancy protection ineffective. By proactively triggering alarms to urge timely hard drive replacement and full disk reconstruction, this mechanism successfully prevents potential data loss risks in extreme cases, ensuring that the embodiment can pursue higher resource utilization and faster reconstruction speed without sacrificing the ultimate data reliability of the storage system.

[0022] In one possible implementation, after triggering a replacement alarm for the second hard drive, the method further includes: In response to the completion of the replacement of the second hard drive, a full data reconstruction is performed on the newly replaced hard drive based on the reconstructed data stored in the redundant storage resources and the data of other hard drives in the storage system, in order to restore the redundant protection state of the storage system.

[0023] This embodiment systematically solves the long-term redundancy and degradation problem that may be caused by the introduction of partial reconstruction by combining manual replacement guided by trigger-based alarms with subsequent automated full reconstruction, ensuring that the implementation will not affect the final data security of the storage system.

[0024] According to a second aspect of the embodiments of this application, a hard disk failure handling apparatus is provided, the apparatus comprising: The first logical address acquisition module is used to acquire the first logical address range corresponding to the faulty head in response to the detection of a faulty head on the first hard disk in the storage system. The storage stripe cell determination module is used to determine the target storage stripe cell affected by the faulty head based on a first logical address range; The data reconstruction and writing module is used to reconstruct the data of the target storage stripe unit and write the reconstructed data into the redundant storage resources of the storage system.

[0025] According to a third aspect of the embodiments of this application, a computing device is provided. The computing device includes a memory and a processor, the memory storing a computer program, and the processor executing the program to implement the method as described above.

[0026] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in the embodiments of this application.

[0027] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described above in the embodiments of this application. Attached Figure Description

[0028] More details, features, and advantages of embodiments of the present application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A schematic diagram of a server architecture provided for an exemplary embodiment of this application; Figure 2 A schematic diagram of a RAID controller structure provided in an exemplary embodiment of this application; Figure 3 A schematic diagram of the internal modules and data structures of an HDD provided in an exemplary embodiment of this application; Figure 4 A schematic diagram illustrating the process and principle of data reconstruction and access redirection provided for an exemplary embodiment of this application; Figure 5 A schematic diagram illustrating a second partial reconstruction and triggering of replacement provided for an exemplary embodiment of this application; Figure 6 A flowchart of a hard disk failure handling method provided in an exemplary embodiment of this application; Figure 7 for Figure 6 Flowchart of step S610; Figure 8 A flowchart of a hard disk failure handling method provided as yet another exemplary embodiment of this application; Figure 9 for Figure 6 Flowchart of step S630; Figure 10 A schematic block diagram of the functional modules of a hard disk failure handling device provided in an exemplary embodiment of this application; Figure 11 A structural block diagram of a computing device provided for an exemplary embodiment of this application. Detailed Implementation

[0029] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that embodiments of this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the embodiments of this application. It should be understood that the accompanying drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0030] It should be understood that the various steps described in the method implementation of this application may be performed in different orders and / or in parallel. Furthermore, the method implementation may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0031] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in the embodiments of this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0032] It should be noted that the terms "one" and "more" mentioned in the embodiments of this application are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0033] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0034] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device. It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of this application's embodiments. Other methods that comply with relevant laws and regulations can also be applied to the implementation of this application's embodiments.

[0035] like Figure 1 As shown, Figure 1The server architecture diagram provided in this application embodiment includes a server host (HOST), which includes components such as a CPU. The server also includes a RAID (redundant arrays of independent disks) card, a hard disk backplane, and multiple HDDs (Hard Disk Drives).

[0036] The host can connect to the RAID card via the PCIe (peripheral component interconnect express) bus to send data read / write requests and configuration management commands to the RAID card.

[0037] As the core component of storage control, the RAID card communicates with the host through the PCIe interface and connects to the hard drive backplane through the SAS (serial attached SCSI) or SATA (serial advanced technology attachment) interface.

[0038] The hard drive backplane provides multiple SAS / SATA physical ports, which can be connected to multiple independent HDDs to form a disk array that supports redundancy protection.

[0039] In this embodiment, multiple HDDs are configured into a RAID group with data redundancy protection to improve data reliability and availability. Common RAID levels with redundancy protection capabilities include, but are not limited to, RAID 1, RAID 5, RAID 6, and nested levels derived from them, such as RAID 10, RAID 50, and RAID 60.

[0040] In this architecture, the RAID card is responsible for executing RAID algorithms, fault detection, data reconstruction, and access scheduling, and is the hardware foundation for realizing fault isolation and local reconstruction at the head level in the embodiments of this application.

[0041] The solution provided in this application mainly consists of a RAID controller (i.e., a RAID card) and its firmware, which work in conjunction with an HDD. This RAID controller can be a dedicated RAID control chip, firmware / software running on a general-purpose processor, or a combination of chip and firmware; the embodiments are not limited to these.

[0042] Figure 2 This application illustrates an exemplary division of the internal functional modules of a RAID controller according to an embodiment of the present application. Figure 2 The dark background areas represent the modules primarily involved in the embodiment. For example... Figure 2 As shown, the RAID controller mainly includes the following modules: Front-end PCIe port: Serves as the physical and protocol interface for communication between the RAID controller and the server host. It conforms to the PCI Express specification and is responsible for receiving data read / write I / O commands and management commands from the host.

[0043] PCI Function Module: As a standard PCIe device functional unit, it implements the configuration space, register set, and related processing logic required by the PCIe specification.

[0044] Front-end processing module: Responsible for parsing various commands received through the front-end PCIe port and distributing them to different processing modules according to their type. Business read and write commands are directed to the cache module or sent directly to the RAID algorithm module, while configuration and management commands are sent to the configuration management module.

[0045] Cache module: This is an optional module responsible for managing the cache of read and write data and executing relevant caching algorithms to improve I / O performance. The specific implementation of this module depends on whether the RAID controller is equipped with dedicated dynamic random access memory.

[0046] Configuration Management Module: This module is responsible for handling storage system configuration transactions, including but not limited to the creation and deletion of RAID groups, and the discovery and status management of hard drives. In this embodiment, this module is particularly important for receiving and parsing head fault error codes reported by hard drives, and for initiating and parsing queries for detailed information on faulty heads, thereby achieving fine-grained management of hard drive head-level fault status.

[0047] RAID Algorithm Module: Responsible for executing specific RAID algorithms (such as XOR parity in RAID 5). Its functions include: converting logical I / O commands issued by the host into parallel read / write commands for multiple physical hard drives; and, in degraded or reconstructed states, calculating and initiating local data reconstruction tasks for specific stripe cells based on the faulty head location information provided by the configuration management module, rather than a full disk reconstruction.

[0048] Backend processing module: Responsible for communicating with the physical hard drive. This module receives commands from the RAID algorithm module and configuration management module, encapsulates them into hard drive-recognizable protocol instructions (such as SAS or SATA commands), sends them to the hard drive through the corresponding interface, and processes the responses and data returned by the hard drive.

[0049] The functions of the above modules can be implemented through dedicated hardware circuits in the RAID controller chip, through firmware programs running on the processor, or through a combination of hardware and firmware.

[0050] Figure 3 This is a schematic diagram of the internal modules and data structures of the HDD involved in the embodiments of this application.

[0051] like Figure 3 As shown, a hard drive contains multiple physical platters, and each platter can be equipped with one or more heads for reading and writing data on the platter surface.

[0052] Each read / write head is responsible for accessing one or more storage areas on the disk. Logically, these storage areas are identified and managed by the LBA (Level Analyzer). For example... Figure 3 As shown on the right, the logical memory space corresponding to a read / write head may contain multiple LBA segments. Each LBA segment is a contiguous address space, defined by a start LBA and an end LBA.

[0053] Therefore, the HDD firmware can maintain and know the potentially discontinuous logical address space information managed by each head. When a head fails, the HDD can respond to the RAID controller's query and accurately report one or more specific LBA ranges (i.e., LBA segments) affected by the failed head, rather than reporting the entire hard drive as a failure. This provides a basis for the RAID controller to perform subsequent accurate isolation and partial reconstruction.

[0054] like Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the process and principle of reporting head-level fault information, reconstructing local data, and redirecting access when a single hard drive in a RAID5 group experiences a head failure, as provided in this embodiment of the application.

[0055] This embodiment takes the most common RAID 5 group as an example, combined with Figure 4 This document details the specific process of fault handling and data reconstruction in the embodiments of this application, which is based on the magnetic head.

[0056] Assume a RAID 5 group consists of four hard drives (drive 1, drive 2, drive 3, and drive 4) and a hot spare drive. When a head on drive 1 fails, the procedure is as follows: (1) Fault reporting and information acquisition.

[0057] When responding to read and write commands from the RAID controller, disk 1 will return a response containing a specific error code. This error code indicates that a head-level failure has occurred, rather than a complete hard drive failure.

[0058] After the RAID controller (specifically its configuration management module) parses this error code, it immediately sends a head information query command to disk 1.

[0059] Disk 1 responds to the query command and returns detailed information about the faulty head, including the number of LBA segments affected by the head and the start and end addresses of each LBA segment.

[0060] (2) Analysis of the scope of influence and local reconstruction.

[0061] Based on the obtained LBA range and the data distribution rules of RAID 5, the RAID controller calculates the stripe cells affected by the faulty head. Figure 4 In the example, the stripe cells that store data blocks D1 and D13 are affected.

[0062] Subsequently, the RAID controller initiates a partial reconstruction. It reads data from other healthy hard drives in the same RAID stripe (e.g., for the stripe containing D1, it reads D2 from drive 2, D3 from drive 3, and the parity P from drive 4), uses the RAID 5 parity algorithm to calculate the data (D1) that the faulty head should have stored, and then writes the reconstructed data to the corresponding location on the hot spare drive (i.e., the D1 location on the hot spare drive). The process for D13 is similar. This process only reconstructs the affected individual stripes, and the amount of data is much smaller than a full disk reconstruction.

[0063] (3) Isolation and access redirection.

[0064] After completing the partial reconstruction, the RAID controller implements an isolation strategy based on the number of read / write heads: only the LBA range (i.e., D1 and D13 areas) corresponding to the faulty head is marked as inaccessible, while the remaining healthy heads and their data areas (such as D4, D7, P, etc.) on disk 1 remain in a normal and usable state.

[0065] For subsequent I / O access requests, the RAID controller intelligently determines and redirects them: If the requested address is not within the fault LBA range of disk 1, the request will still be processed normally by disk 1.

[0066] If the requested address falls within the fault LBA range of disk 1 (such as D1 or D13), the request will be automatically redirected to the corresponding location on the hot spare disk where the reconstructed data has been stored for processing, thus achieving degraded read and write.

[0067] Through the above process, the embodiments of this application achieve tolerance for single head failures, avoid the abandonment of the entire hard drive due to a single head failure, significantly reduce the overall failure rate of the hard drive, and shorten the reconstruction time due to the significant reduction in the amount of reconstructed data.

[0068] This embodiment further considers the potential risks that local reconstruction may bring. For example... Figure 5 As shown, Figure 5 Is Figure 4The diagram illustrates how, based on the state shown, a second partial reconstruction is performed and a replacement is triggered when the second hard drive in the RAID5 group experiences a head failure that affects the same stripe.

[0069] Combination Figure 5 As shown, based on the above state, if the second hard drive in the RAID group (e.g., disk 3) also experiences a head failure, and its failure area (e.g., D3 and D15) happens to be on the same stripe as the failure area (D1 and D13) of disk 1, after the system completes the second partial reconstruction of the failure area of ​​disk 3, it will recognize that multiple data blocks (e.g., D1 and D3 are on the same stripe) have been stored on the hot spare disk.

[0070] This state means that if the hot spare disk itself fails, the data on that stripe will be permanently lost, and the RAID group's redundancy protection capability on that stripe will be essentially lost. To avoid this risk, after completing this partial reconstruction, the RAID controller will immediately trigger a replacement alarm for the newly failed hard drive (disk 3) (e.g., by illuminating the hard drive failure indicator light, sending an alarm message to the server management controller, etc.), prompting the user to replace the hard drive. After the user replaces the hard drive, the system can use the existing full-disk reconstruction function to restore the data to the new hard drive, thereby restoring the RAID group to its full redundancy protection state.

[0071] The design principles and processes for RAID 5 in this embodiment can be applied analogously to other RAID levels with data redundancy protection, such as RAID 1, RAID 6, and RAID 10.

[0072] Based on the above embodiments, this application also provides a hard disk failure handling method. This method can be applied to the system architecture provided in the above embodiments and executed by the RAID controller therein. Figure 6 As shown, the method may include the following steps: In step S610, in response to detecting a faulty read / write head on the first hard disk in the storage system, the first logical address range corresponding to the faulty read / write head is obtained.

[0073] In this embodiment, the scope of the fault can be defined by the RAID controller receiving specific error codes reported by the hard drive and actively querying detailed head information.

[0074] In step S620, the target memory stripe cell affected by the faulty head is determined based on the first logical address range.

[0075] The RAID controller can locate the specific stripe unit that needs to be processed based on the acquired LBA range information and the stripe mapping rules of the current RAID group, thereby achieving fine-grained location of the impact of the fault.

[0076] In step S630, the target storage stripe cell is reconstructed, and the reconstructed data is written into the redundant storage resources of the storage system.

[0077] This step performs a partial reconstruction, using only other normal data blocks and verification information within the same stripe to recover the faulty data and store it in the corresponding location of redundant storage resources, thus avoiding a full data migration.

[0078] This embodiment addresses the issue of high hard drive failure rates and long reconstruction times caused by single-head failures in related technologies. It reduces the granularity of fault management and data reconstruction from the entire hard drive to individual read / write heads. By identifying and obtaining the specific logical address range of the faulty head, it locates the affected specific storage stripe units. Data reconstruction is performed only on these limited stripe units, and redundant resources are stored. Simultaneously, access isolation and redirection strategies are implemented to block only the faulty area while ensuring normal service for the remaining healthy parts of the hard drive. This solves the problems of high hard drive failure rates and long reconstruction times caused by single-head failure triggering full disk replacement and reconstruction. It achieves significant reduction in maintenance costs and improved resource utilization while maintaining storage system reliability.

[0079] Based on the above embodiments, in another embodiment provided in this application, as a specific refinement of responding to the detection of a faulty read / write head on the first hard disk in the storage system, the above step S610 may specifically be: obtaining a first response message of the first hard disk, the first response message containing an error code indicating the faulty read / write head.

[0080] In this embodiment, the error code is different from the general error code that identifies a complete hard drive failure, enabling the RAID controller to clearly distinguish that the failure occurs at the head level, thereby triggering a subsequent fine-grained processing procedure for the head, rather than isolating the entire disk.

[0081] This embodiment introduces and defines dedicated error codes to indicate head failures, establishing a communication mechanism between the hard drive and the RAID controller regarding head-level fault status. This not only enables rapid and accurate identification of the root cause of the fault but also provides a decision-making basis for subsequent isolation and reconstruction at the logical address range granularity, ensuring that the system can evolve from the traditional disk-level management mode to a fine-grained head-level management mode.

[0082] Based on the above embodiments, in another embodiment provided in this application, as a refinement of obtaining the first logical address range corresponding to the faulty magnetic head, such as... Figure 7 As shown, step S610 above may specifically include the following steps: Step S611: Send a head information query command to the first hard disk.

[0083] In this embodiment, the command is specifically designed to request detailed information about a particular head and is initiated proactively by the RAID controller after it has initially learned of a head failure (e.g., by receiving a response containing a specific error code).

[0084] Step S612: Receive second response information sent by the first hard disk; wherein the second response information includes description information of the first logical address range.

[0085] In the embodiments, this descriptive information typically includes, but is not limited to: the number of affected logical address segments (LBA segments), and the start logical block address (LBA) and end logical block address of each LBA segment.

[0086] This embodiment, through a proactive command-response interaction mechanism, enables an accurate description of the impact range of a faulty read / write head. The RAID controller can obtain precise location information of the fault within the hard drive's logical space, rather than a general fault signal. This allows subsequent isolation and reconstruction operations to be strictly limited to the affected, potentially discontinuous, specific LBA intervals, thereby ensuring the accuracy of localized processing and preventing healthy areas from being mistakenly isolated.

[0087] In another embodiment provided in this application, the specific data structure of the description information of the first logical address range during the above-mentioned interaction process is clearly defined. This description information specifically includes: the number of logical address segments, and the starting and ending logical block addresses of each logical address segment. Through this set of data, multiple logical memory regions that may be physically discontinuous and are managed by a single read / write head can be accurately described.

[0088] This embodiment explicitly quantifies the jurisdiction of the read / write head into a logical address range defined by one or more start and end LBA pairs. This provides the RAID controller with accurate fault location information. This allows the system to perform isolation and reconstruction operations with minimal granularity, avoiding erroneous isolation or redundant reconstruction of healthy storage areas.

[0089] Based on the above embodiments, in another embodiment provided in this application, such as Figure 8 As shown, after writing the reconstructed data to the redundant storage resources of the storage system, i.e., after step S630 above, the method may further include the following steps: Step S641: When receiving an access request to the first hard disk, determine whether the target logical address sought by the access request is within the range of the first logical address.

[0090] In this embodiment, for example, when an input / output (I / O) access request to the first hard disk is received, it is determined whether the target logical address addressed by the access request is within the first logical address range (i.e., the LBA range affected by the faulty read / write head). This step enables dynamic access control decisions by comparing the target address of each I / O request in real time.

[0091] Step S642: When the target logical address is within the range of the first logical address, the access request is redirected to the corresponding address of the redundant storage resource for processing.

[0092] If the determination result is yes, meaning the target logical address is within the first logical address range, the access request will be redirected to the location corresponding to the target logical address in redundant storage resources (such as a hot spare disk) for processing. This means that read and write access to the faulty area will be transparently served by the redundant resources storing the reconstructed data.

[0093] The aforementioned real-time assessment and redirection mechanism enables dynamic and lossless isolation of access to faulty areas. This ensures that application access requests to the area where the faulty head is located are processed seamlessly and correctly, while blocking direct access to physically damaged areas. This maintains the storage system's business continuity while maximizing the availability and performance of healthy storage media within the faulty hard drive.

[0094] Step S643: When the target logical address of the access request is within the range of the second logical address, the access request is sent to the first hard disk.

[0095] In this embodiment, when the target logical address is not within the first logical address range, that is, when the target logical address belongs to the healthy area (second logical address range) of the first hard disk that is not affected by the faulty read / write head, the access request is directly sent to the first hard disk for processing, and the healthy read / write head of the first hard disk performs normal read / write operations.

[0096] In this embodiment, when an access request to the first hard disk is received, and it is determined in step S641 that the target logical address of the access request is within the second logical address range (i.e., the healthy logical address range in the first hard disk that is not affected by the faulty head), the access request can be directly sent to the first hard disk for processing without any redirection operation.

[0097] This embodiment clarifies the access path for healthy hard disk regions, which, together with the isolation and redirection mechanism for faulty regions, constitutes a complete I / O scheduling strategy. Through this strategy, the system can dynamically and accurately distinguish the access target of each I / O request. For faulty regions, data accessibility is ensured through redirection; for healthy regions, the original direct access path is maintained. This ensures that while tolerating local head failures, performance overhead is minimized, and the overall I / O processing efficiency and low latency of the system are maintained, achieving a balance between fault tolerance and performance optimization.

[0098] Based on the above embodiments, in another embodiment provided in this application, during the data reconstruction process of the target storage stripe cell, as follows: Figure 9 As shown, step S630 above may specifically include the following steps: Step S631: Read the data blocks in the target storage stripe unit except for the data block corresponding to the faulty head.

[0099] In this embodiment, the RAID controller sends read commands to all other normal hard drives (including data disks and parity disks) in the RAID group where the stripe unit is located, in order to obtain all surviving data blocks and parity information required for reconstruction.

[0100] Step S632: Based on a preset redundancy algorithm, the reconstructed data of the data block corresponding to the faulty head is calculated using other data blocks.

[0101] For example, in RAID 5, the XOR parity algorithm is used; in RAID 6, more complex parity algorithms such as Reed-Solomon codes are used to calculate the data read, thereby accurately recovering the data that the faulty head should have stored.

[0102] This embodiment ensures accurate recovery of faulty data by explicitly decomposing the reconstruction process into data collection and verification calculations. It can strictly limit the consumption of computing resources and I / O bandwidth to the few necessary stripes affected by the fault, thereby achieving the goal of restoring data availability with minimal system overhead. This is a key technical implementation path to significantly shorten reconstruction time and reduce system load.

[0103] Based on the above embodiments, in order to address the complex scenario of multiple head failures in a storage system, in another embodiment provided in this application, the method may further include: (1) In response to a head failure in the second hard disk in the storage system, determine the third logical address range affected by the faulty head in the second hard disk.

[0104] This step is similar to the process for the first hard drive, namely, defining the scope of the impact of the new faulty head.

[0105] (2) If the storage stripe unit corresponding to the third logical address range belongs to the same stripe as any target storage stripe unit that has completed data reconstruction and is stored in redundant storage resources, a replacement alarm for the second hard disk is triggered.

[0106] In this embodiment, it can be determined whether the storage stripe unit corresponding to the third logical address range belongs to the same stripe as any target storage stripe unit that has completed data reconstruction and is stored in redundant storage resources (such as a hot spare disk). If the determination result is yes, that is, within the same stripe, a faulty data block from the first hard drive has been reconstructed and stored in the redundant resources, and the failure of the second hard drive has affected another data block within the stripe, then a replacement alarm for the second hard drive is triggered. This alarm is intended to prompt the system administrator or upper-level management system that the second hard drive needs to be replaced to restore the full redundancy protection capability of the RAID group.

[0107] This embodiment effectively identifies high-risk scenarios where multiple partial failures cause too many data blocks within the same RAID stripe to concentrate on a single hot spare disk, effectively rendering redundancy protection ineffective. By proactively triggering alarms to urge timely hard drive replacement and full disk reconstruction, this mechanism successfully prevents potential data loss risks in extreme cases, ensuring that the embodiment can pursue higher resource utilization and faster reconstruction speed without sacrificing the ultimate data reliability of the storage system.

[0108] In another embodiment provided in this application, after triggering a replacement alarm for the second hard drive, the method further includes a complete recovery operation to ensure that the storage system eventually returns to a protected state. Specifically, the method may further include: in response to the completion of the replacement of the second hard drive by the new hard drive (i.e., the system detects that the new hard drive has been correctly installed and brought online), performing a full data reconstruction on the newly replaced hard drive based on the reconstructed data stored in the redundant storage resources and the data of other hard drives in the storage system (including the first hard drive and other normal hard drives). This reconstruction process will completely rebuild and write all the data that should belong to the second hard drive (including the data in its healthy head area, as well as the data that was temporarily stored in the redundant resources due to head failure) to the new hard drive, thus performing a full data reconstruction on the newly replaced hard drive.

[0109] This embodiment systematically solves the long-term redundancy and degradation problem that may be caused by the introduction of partial reconstruction by combining manual replacement guided by trigger-based alarms with subsequent automated full reconstruction, ensuring that the implementation will not affect the final data security of the storage system.

[0110] By dividing each function into corresponding functional modules, this application provides a hard disk fault handling device, which can be a server, a terminal, or a chip applied to a server. Figure 10This is a schematic block diagram of the functional modules of a hard disk failure handling apparatus provided in an exemplary embodiment of this application. Figure 10 As shown, the hard drive failure handling device includes: The first logical address acquisition module 81 is used to acquire the first logical address range corresponding to the faulty head in response to the detection of a faulty head on the first hard disk in the storage system. The storage stripe cell determination module 82 is used to determine the target storage stripe cell affected by the faulty head based on a first logical address range; The data reconstruction and writing module 83 is used to reconstruct the data of the target storage stripe unit and write the reconstructed data into the redundant storage resources of the storage system.

[0111] This embodiment addresses the issue of high hard drive failure rates and long reconstruction times caused by single-head failures triggering full disk replacement and reconstruction. It improves storage system reliability by maintaining overall system reliability while significantly reducing maintenance costs and improving resource utilization. This approach shifts the focus of fault management and data reconstruction from the entire hard drive to individual heads. By identifying and obtaining the specific logical address range of the faulty head, the affected storage stripe cells are located. Only these limited stripe cells undergo partial data reconstruction, and redundant resources are stored.

[0112] In another embodiment provided in this application, the first logical address acquisition module 81 is specifically used for: Obtain the first response message from the first hard drive. The first response message contains an error code indicating a faulty read / write head.

[0113] This embodiment introduces and defines dedicated error codes to indicate head failures, establishing a communication mechanism between the hard drive and the RAID controller regarding head-level fault status. This not only enables rapid and accurate identification of the root cause of the fault but also provides a decision-making basis for subsequent isolation and reconstruction at the logical address range granularity, ensuring that the system can evolve from the traditional disk-level management mode to a fine-grained head-level management mode.

[0114] In another embodiment provided in this application, the first logical address acquisition module 81 is further configured to: Send a head information query command to the first hard drive; Receive the second response information sent by the first hard disk, the second response information containing description information of the first logical address range.

[0115] This embodiment, through a proactive command-response interaction mechanism, enables a precise description of the impact range of a faulty read / write head. The RAID controller can obtain precise location information of the fault within the hard drive's logical space, rather than a general fault signal. This allows subsequent isolation and reconstruction operations to be strictly limited to the affected, potentially discontinuous, specific LBA intervals, thereby ensuring the accuracy of localized processing and preventing healthy areas from being mistakenly isolated.

[0116] In another embodiment provided in this application, the description information of the first logical address range includes: the number of logical address segments, and the starting logical block address and the ending logical block address of each logical address segment.

[0117] This embodiment explicitly quantifies the jurisdiction of the read / write head into a logical address range defined by one or more start and end LBA pairs. This provides the RAID controller with precise fault location information. This allows the system to perform isolation and reconstruction operations with minimal granularity, avoiding accidental isolation or redundant reconstruction of healthy storage areas.

[0118] In another embodiment provided in this application, the device may further include an access control module, specifically used for: When receiving an access request to the first hard disk, determine whether the target logical address sought by the access request is within the range of the first logical address; When the target logical address is within the first logical address range, the access request is redirected to the corresponding address of the redundant storage resource for processing.

[0119] This embodiment achieves dynamic and lossless isolation of access to faulty areas through the aforementioned real-time judgment and redirection mechanism. It ensures that application access requests to the area where the faulty head is located are processed seamlessly and correctly, while blocking direct access to physically damaged areas. This maintains the business continuity of the storage system while maximizing the availability and performance of healthy storage media within the faulty hard drive.

[0120] In another embodiment provided in this application, the apparatus further includes a request sending module, configured to: When the target logical address of the access request is within the range of the second logical address, the access request is sent to the first hard disk for processing.

[0121] This embodiment clarifies the access path for healthy hard disk regions, which, together with the isolation and redirection mechanism for faulty regions, constitutes a complete I / O scheduling strategy. Through this strategy, the system can dynamically and accurately distinguish the access target of each I / O request. For faulty regions, data accessibility is ensured through redirection; for healthy regions, the original direct access path is maintained. This ensures that while tolerating local head failures, performance overhead is minimized, and the overall I / O processing efficiency and low latency of the system are maintained, achieving a balance between fault tolerance and performance optimization.

[0122] In another embodiment provided in this application, the data reconstruction and writing module 83 is specifically used for: Read all data blocks in the target storage stripe cell except for the data block corresponding to the faulty head; Based on a preset redundancy algorithm, the reconstructed data of the data block corresponding to the faulty head is calculated using other data blocks.

[0123] This embodiment ensures accurate recovery of faulty data by explicitly decomposing the reconstruction process into data collection and verification calculations. It can strictly limit the consumption of computing resources and I / O bandwidth to the few necessary stripes affected by the fault, thereby achieving the goal of restoring data availability with minimal system overhead. This is a key technical implementation path to significantly shorten reconstruction time and reduce system load.

[0124] In another embodiment provided in this application, the device further includes an alarm triggering module, specifically used for: In response to a head failure in the second hard drive of the storage system, determine the third logical address range affected by the failed head in the second hard drive; If the storage stripe unit corresponding to the third logical address range belongs to the same stripe as any target storage stripe unit that has completed data reconstruction and is stored in redundant storage resources, a replacement alarm for the second hard drive is triggered.

[0125] This embodiment effectively identifies high-risk scenarios where multiple partial failures cause too many data blocks within the same RAID stripe to concentrate on a single hot spare disk, effectively rendering redundancy protection ineffective. By proactively triggering alarms to urge timely hard drive replacement and full disk reconstruction, this mechanism successfully prevents potential data loss risks in extreme cases, ensuring that the embodiment can pursue higher resource utilization and faster reconstruction speed without sacrificing the ultimate data reliability of the storage system.

[0126] In another embodiment provided in this application, the device further includes a data reconstruction module, specifically used for: In response to the completion of the replacement of the second hard drive, a full data reconstruction is performed on the newly replaced hard drive based on the reconstructed data stored in the redundant storage resources and the data of other hard drives in the storage system, in order to restore the redundant protection state of the storage system.

[0127] This embodiment systematically solves the long-term redundancy and degradation problem that may be caused by the introduction of partial reconstruction by combining manual replacement guided by trigger-based alarms with subsequent automated full reconstruction, ensuring that the implementation will not affect the final data security of the storage system.

[0128] This application also provides a computing device, including: at least one processor; and a memory for storing at least one processor-executable instruction; wherein the at least one processor is configured to execute instructions to implement the method disclosed in this application. Specifically, the computing device may be... Figure 1 The corresponding server.

[0129] The aforementioned processor can also be called a central processing unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this application can be implemented by integrated logic circuits in the processor's hardware or by software instructions. The aforementioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in memory, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0130] This application also provides a computing device, such as... Figure 11 As shown, Figure 11This is a schematic diagram of a computing device provided in an embodiment of this application. The computing device can specifically be the server described above, including a processor 1101, a communication interface 1102, a memory 1103, a communication bus 1104, a RAID card 1105, and a hard disk backplane 1106. The processor 1101, communication interface 1102, memory 1103, RAID card 1105, and hard disk backplane 1106 communicate with each other through the communication bus 1104. The hard disk backplane 1106 can be connected to multiple HDDs.

[0131] Memory 1103 is used to store computer programs; The processor 1101 is used to execute the program stored in the memory 1103 to implement the method described above in the embodiments of this application.

[0132] The communication bus mentioned in the computing device above can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0133] The communication interface is used for communication between the aforementioned computing device and other devices.

[0134] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0135] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0136] This application also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by the processor of a server, the server is able to perform the methods disclosed in the embodiments of this application.

[0137] The computer-readable storage medium in this application embodiment may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.

[0138] The aforementioned computer-readable medium may be included in the aforementioned server; or it may exist independently and not assembled into the server.

[0139] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a processor, implements the methods disclosed in the embodiments of this application.

[0140] In embodiments of this application, computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0142] The modules, components, or units described in the embodiments of this application can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0143] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0144] The above description is merely an embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

[0145] While specific embodiments of this application have been described in detail by way of examples, those skilled in the art should understand that the above examples are for illustrative purposes only and are not intended to limit the scope of this application. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this application. The scope of this application is defined by the appended claims.

Claims

1. A hard disk failure handling method, characterized in that, The method includes: In response to the detection of a faulty read / write head on the first hard disk in the storage system, the first logical address range corresponding to the faulty read / write head is obtained; Based on the first logical address range, the target memory stripe cell affected by the faulty head is determined; The target storage stripe unit is reconstructed, and the reconstructed data is written into the redundant storage resources of the storage system.

2. The method according to claim 1, characterized in that, The response to detecting a faulty read / write head on the first hard drive in the storage system includes: Obtain the first response message from the first hard drive, the first response message containing an error code indicating a faulty read / write head.

3. The method according to claim 1, characterized in that, The step of obtaining the first logical address range corresponding to the faulty head includes: Send a head information query command to the first hard disk; Receive second response information sent by the first hard disk, the second response information containing description information of the first logical address range.

4. The method according to claim 3, characterized in that, The description information of the first logical address range includes: the number of logical address segments, and the starting logical block address and ending logical block address of each logical address segment.

5. The method according to claim 1, characterized in that, After writing the reconstructed data to the redundant storage resources of the storage system, the method further includes: When receiving an access request to the first hard disk, determine whether the target logical address addressed by the access request is within the range of the first logical address; When the target logical address is within the range of the first logical address, the access request is redirected to the corresponding address of the redundant storage resource for processing.

6. The method according to claim 5, characterized in that, The method further includes: When the target logical address of the access request is within the range of the second logical address, the access request is sent to the first hard disk.

7. The method according to claim 1, characterized in that, The data reconstruction of the target storage stripe cell includes: Read the data blocks in the target storage stripe unit, excluding the data block corresponding to the faulty head; Based on a preset redundancy algorithm, the reconstructed data of the data block corresponding to the faulty head is calculated using the other data blocks.

8. The method according to claim 1, characterized in that, The method further includes: In response to a head failure in the second hard disk of the storage system, a third logical address range affected by the failed head in the second hard disk is determined; If the storage stripe unit corresponding to the third logical address range belongs to the same stripe as any of the target storage stripe units that have completed data reconstruction and are stored in the redundant storage resources, a replacement alarm for the second hard disk is triggered.

9. The method according to claim 8, characterized in that, After triggering the replacement alarm for the second hard drive, the method further includes: In response to the completion of the replacement of the second hard drive, a full data reconstruction is performed on the newly replaced hard drive based on the reconstructed data stored in the redundant storage resources and the data of other hard drives in the storage system, so as to restore the redundant protection state of the storage system.

10. A computing device, characterized in that, include: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any one of claims 1-9.

Images