RAID (Redundant Array of Independent Disks) multi-stripe parallel writing method

Abstract

The invention discloses an RAID (redundant array of independent disks) multi-stripe parallel write-in method, which comprises the following steps: after each MCU core receives a new write command, if a stripe write command exists in a command set and if deadlock conflicts exist between other stripes and the current stripe write command to be processed, the write-in of the current stripe write command to be processed is stopped, and if the MCU core receives new other stripe write later, the write-in of the current stripe write command to be processed is stopped. And if yes, the stripe is inevitably not conflicted with the parity command of which the writing is paused. Through the method described by the invention, the multi-channel write command issuing logic can be simplified, the problem of multi-stripe deadlock can be solved, only statistics and rearrangement of commands are needed in a single core, extra overhead of inter-core synchronization is avoided, and the efficiency and the performance are improved.

Description

Technical Field

[0001] The present invention relates to the field of computer storage, and in particular to a method for parallel writing of multiple stripes of RAID. Background Art

[0002] The stripe of RAID5 consists of N data plus one parity data. The MCU operates the storage module to write the N data in parallel to an independent storage logic unit (LUN). At the same time, each data also enters the XOR ENGINE module for XOR calculation. Finally, after all N data are XORed, a parity data is generated. The MCU also stores the parity data in an independent storage logic unit LUN. Since the generation of parity data depends on the final XOR result of the previous N data, there is a mandatory order here, and the parity data should be written last. For normal data writing, see the attached Figure 1 , parity data is written and attached Figure 2 . However, in actual applications, for a single-stripe scenario, since all LUNs can be operated in parallel, there is no need to enforce constraints on the order in which stripe N+1 data is sent. However, when multiple stripes are written in parallel, if on one LUN the order is stripe A's parity Ap followed by stripe B's data Bn, on another LUN the order is stripe B's parity Bp followed by stripe A's data An. At this time, Ap writes depend on An being written first, but An is blocked by Bp and depends on Bp being written first. Bp writes depend on Bn being written first, but Bn's write is blocked by Ap, so this causes a deadlock. See attached. Figure 3 .

[0003] For this problem, the industry's usual practice is to record the order of stripes and avoid interleaving two stripes by reordering commands. However, as storage capacity increases and the number of LUNs increases, more and more storage devices use multiple MCU cores to manage LUNs. Each MCU core only manages a part of the LUNs, so each MCU core cannot record the situation of the entire stripe. In this case, a context shared by all cores is required to reorder multiple stripes, which has the overhead of synchronization between cores and is inefficient. Summary of the invention

[0004] The purpose of the present invention is to provide a method for implementing RAID protection of a storage medium, which can avoid the problem of mutual deadlock when multiple MCUs simultaneously process multiple stripes and write in parallel, while improving the inspection efficiency and avoiding additional synchronization operations between multiple MCUs.

[0005] In order to achieve the above-mentioned purpose, the present invention is implemented through the following technical solutions.

[0006] A method for parallel writing of multiple stripes of RAID, comprising the steps of: (1) Send the command to the MCU core; (2) After each MCU core receives a new write command, it determines whether there is a stripe parity write command in the received command set; (3) If there is no stripe parity write command in the command set, no special processing is required; (4) If there is a stripe parity write command in the command set, determine whether other stripes have a deadlock conflict with the current pending stripe parity write command. If so, suspend writing the current pending stripe parity write command; (5) If all the preceding data of the stripe where the current parity write command is located has been written, and there is no deadlock conflict between other stripes and the current stripe parity write command, write the parity data of the stripe to be processed.

[0007] Furthermore, the order of the preamble data and parity data in each stripe is preserved.

[0008] Furthermore, the method for determining in step (4) whether other stripes have a deadlock conflict with the parity write command of the current stripe is as follows: Check the write status of all stripe commands of the current MCU core, and mark the stripe with unfinished write commands as a questionable stripe; When the MCU core receives a new write command belonging to a doubtful stripe and the command is not a stripe parity write, the doubtful stripe mark is cancelled and the stripe is restored to a normal stripe; When other stripes are common stripes, it is considered that there is no deadlock conflict between other stripes and the parity write command of the stripe to be processed.

[0009] Further, determining whether there is an uncompleted write command in the stripe includes the following steps: After each MCU core receives a new write command message, if it is not a stripe parity write, it will increase the ENG N command count corresponding to the MCU context stripe by one according to the XORENGINE number N in the command; Each MCU core checks the hardware result and determines whether the write command is completed. If it is not a stripe pair write, it operates the ENG N command count corresponding to this MCU context stripe minus one according to the XOR ENGINE number in the command. After the stripe command count is reduced by one, if the count has been reduced to 0, there is no uncompleted write command in the stripe, otherwise there is an uncompleted write command.

[0010] Furthermore, the number of bitmap positions of the parity stripe to be processed corresponds to the XOR ENGINE number of each stripe, and the command counts of all stripes of the current MCU are checked to obtain the XOR ENGINE numbers of the stripes whose counts are not zero, and the bit positions of the parity bitmap of the stripe to be processed corresponding to these XOR ENGINE numbers are set to one to mark how many other stripes have unfinished write commands before the current parity to be processed is written; After the stripe command count is reduced by one, if the count has been reduced to 0, the corresponding bit is cleared to 0 according to the XOR ENGINE number; When the bitmap of the parity data of the stripe to be processed is completely cleared to 0, the parity data of the stripe to be processed is written.

[0011] Furthermore, after pausing writing of the currently pending stripe parity write command, the stripe parity write command is added to the core parity write pending list; when writing needs to be continued, the command is taken out from the core parity write pending list, and the stripe parity write command is sent to the hardware for parity write operation.

[0012] The advantages of the present invention are: The method described in the present invention can simplify the logic of issuing multi-channel write commands and solve the deadlock problem of multiple stripes. It only needs to count and reorder commands within a single core without any additional inter-core synchronization overhead, thereby improving efficiency and performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a schematic diagram of the writing process of stripe ordinary data in the prior art; Figure 2 It is a schematic diagram of the writing process of stripe parity data in the prior art; Figure 3 It is a schematic diagram of the interlocking of two strips operating in parallel in the prior art; Figure 4 It is a schematic diagram of the architecture of the present invention. DETAILED DESCRIPTION

[0014] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0015] This embodiment provides a method for parallel writing of multiple stripes of RAID, and the specific process is as follows.

[0016] Send the command to the MCU core. Since the data within each stripe is in order, for example, stripe data {D1, D2... Dn, Dp}, after the data is distributed to each MCU core, each MCU core receives an ordered subset. For example, the received subset may be {Dn’, Dp} or {Dn’}, where Dn’ ∈ Dn. Since the data within the stripe is in order, {Dn’, Dp} or {Dn’} is still in order.

[0017] When there are multiple stripes, such as two stripes, stripe A {A1, A2... An, Ap} and stripe B {B1, B2... Bn, Bp}, they are in order before being distributed to multiple MCUs. When n is the same, An is earlier than Bn; when n < n’, An is earlier than An’.

[0018] After the MCU core receives a new write command, it determines whether there is a stripe parity write command in the received command set: If there is no stripe parity write command in the command set, that is, there is no Ap or Bp, no special processing is required and there will be no deadlock.

[0019] If there are both Ap and Bp in the command set and they need to be written to the same lun, due to the ordered data, it proves that all the previous data of stripe A and stripe B have been written, and no special processing is required and there will be no deadlock.

[0020] If there is Ap, and there is also Bn’ on the same lun. If this MCU received a write of stripe B before Ap, it means that Bp may be earlier than Ap, and Ap needs to be blocked from writing and wait for Bn’ to be written first. If the MCU receives a new write of stripe B after receiving Ap, it means that Bp must be later than Ap, and Ap does not need to wait for Bn’ to be written first. Through the following operations, deadlock can be avoided. For the architecture, please refer to Figure 4 。

[0021] Step 1: After each MCU core receives a new write command message, if it is not a stripe parity write, according to the XOR ENGINE number N in the command, increment the command count of stripe ENG N in this MCU context.

[0022] Step 2: Each MCU core checks the hardware result. After determining that the write command is completed, if it is not a stripe pairty write, according to the XOR ENGINE number in the command, decrement the command count of stripe ENG N in this MCU context.

[0023] Step 3: After each MCU core receives a new write command message, if it is a stripe parity write, it checks all the stripe command counts of this MCU. If it is not zero, it changes the corresponding bit position of XOR ENGINE in the parity bitmap to 1 to mark how many other stripes have unfinished write commands before the parity write, and then adds the stripe parity write command to the core parity write pending list.

[0024] Step 4: After each MCU core receives a new write command message, if it is not a stripe parity write, it operates the bitmap of each parity write in the pending list of the core parity write, and clears the bit corresponding to the XORENGINE number to 0 according to the XORENGINE number in the command.

[0025] Step 5: After the stripe command count in step 2 is reduced by one, if the count has been reduced to 0, then according to the XORENGINE number in the command, operate the bitmap written by each parity in the pending list of the core parity write, and clear the bit corresponding to the XORENGINE number to 0.

[0026] Step 6: When the bitmap of a parity write has been completely cleared to 0, the command is taken from the core parity write pending list, and the parity write is sent to the hardware for parity write operation.

[0027] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for parallel writing of multiple stripes of RAID, characterized in that: Includes steps: (1) Send the command to the MCU core; (2) After each MCU core receives a new write command, it determines whether there is a stripe parity write command in the received command set; (3) If there is no stripe parity write command in the command set, no special processing is required; (4) If there is a stripe parity write command in the command set, determine whether other stripes have a deadlock conflict with the current pending stripe parity write command. If so, suspend writing the current pending stripe parity write command; (5) If all the preceding data of the stripe where the current parity write command is located has been written, and there is no deadlock conflict between other stripes and the current stripe parity write command, write the parity data of the stripe to be processed.

2. The RAID multi-strip parallel writing method according to claim 1, characterized in that: The order of the preamble data and parity data in each stripe is preserved.

3. The RAID multi-strip parallel writing method according to claim 1, characterized in that: The method for determining whether other stripes have a deadlock conflict with the parity write command of the current stripe in step (4) is as follows: Check the write status of all stripe commands of the current MCU core, and mark the stripe with unfinished write commands as a questionable stripe; When the MCU core receives a new write command belonging to a doubtful stripe and the command is not a stripe parity write, the doubtful stripe mark is cancelled and the stripe is restored to a normal stripe; When other stripes are common stripes, it is considered that there is no deadlock conflict between other stripes and the parity write command of the stripe to be processed.

4. The RAID multi-strip parallel writing method according to claim 3, characterized in that: Determining whether there is an uncompleted write command in the stripe includes the following steps: After each MCU core receives a new write command message, if it is not a stripe parity write, it will increase the ENG N command count corresponding to the MCU context stripe by one according to the XORENGINE number N in the command; Each MCU core checks the hardware result and determines whether the write command is completed. If it is not a stripe pair write, it operates the ENG N command count corresponding to this MCU context stripe minus one according to the XOR ENGINE number in the command. After the stripe command count is reduced by one, if the count has been reduced to 0, there is no uncompleted write command in the stripe, otherwise there is an uncompleted write command.

5. The RAID multi-strip parallel writing method according to claim 4, characterized in that: The number of bitmap positions of the parity stripe to be processed corresponds to the XOR ENGINE number of each stripe. Check the command counts of all stripes of the current MCU, obtain the XOR ENGINE numbers of the stripes whose counts are not zero, and set the bit positions of the parity bitmap of the stripe to be processed corresponding to these XOR ENGINE numbers to one to mark how many other stripes have unfinished write commands before the current parity to be processed is written; After the stripe command count is reduced by one, if the count has been reduced to 0, the corresponding bit is cleared to 0 according to the XOR ENGINE number; When the bitmap of the parity write of the stripe to be processed has been completely cleared to 0, the parity data of the stripe to be processed is written.

6. The method for parallel writing of multiple RAID stripes according to any one of claims 1 to 5, characterized in that: After pausing writing of the currently pending stripe parity write command, the stripe parity write command is added to the core parity write pending list; when writing needs to be continued, the command is taken out from the core parity write pending list and the stripe parity write command is sent to the hardware for parity write operation.

Images