A method for RAID multi-strip parallel writing

Abstract

The application discloses a RAID multi-strip parallel writing method, and if a new writing command is received by each MCU core, if there is a strip parity writing command in the command set, whether there is a deadlock conflict between other strips and the current to-be-processed strip parity writing command, the writing of the current to-be-processed strip parity writing command is suspended, and if the MCU receives a new other strip writing again, it is indicated that the strip must not have a conflict with the suspended parity command. Through the method described in the application, the multi-channel writing command issuing logic can be simplified, the multi-strip deadlock problem is solved, only the commands need to be counted and rearranged in the single core, there is no additional inter-core synchronization overhead, and the efficiency and performance are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer storage, in particular to a method for RAID multi-strip parallel writing. BACKGROUND

[0002] The strip of RAID5 is composed of N data and one parity data. MCU operates the storage module to write N data in parallel on independent storage logical units (LUN), and each data also enters the XOR ENGINE module to perform XOR calculation. Finally, one parity data is generated after all N data are XORed. MCU also stores the parity data in the independent storage logical unit LUN. Since the generation of parity data depends on the final XOR result of the previous N data, there is a forced sequence here, and the parity data should be written last. The common data writing is shown in Appendix Figure 1 , and the parity data writing is shown in Appendix Figure 2 . However, in actual application, for the single strip scenario, since all LUNs can be operated in parallel, the sequence of N+1 data of the strip does not need to be forced. When multiple strips are written in parallel, if the sequence on one LUN is parity Ap of strip A followed by data Bn of strip B, and the sequence on another LUN is parity Bp of strip B followed by data An of strip A. At this time, Ap is written in dependence on An written first, An is blocked by Bp to be written first, Bp is written in dependence on Bn written first, and Bn is blocked by Ap, thus causing a deadlock, as shown in Appendix Figure 3 .

[0003] For this problem, the industry usually records the sequence of the strip, rearranges the command, and avoids the interlacing of two strips. However, with the increase of storage capacity and the increase of the number of LUNs, more and more storage devices use multiple MCU cores to manage LUNs, and each MCU core only manages a part of LUNs. Therefore, each MCU core cannot record the entire strip, and a context shared by all cores is needed to rearrange multiple strips, which has the overhead of inter-core synchronization and is low in efficiency. SUMMARY

[0004] The present application aims to provide a method for implementing RAID protection of storage media, which can avoid the problem of mutual deadlock when multiple MCUs simultaneously process multiple strip parallel writing, and improve the checking efficiency and avoid the additional synchronization operation between multiple MCUs.

[0005] To achieve the above-mentioned purpose, the present application realizes the following technical scheme.

[0006] A method for RAID multi-strip parallel writing, comprising the steps of:

[0007] (1) issue command to MCU core;

[0008] (2) each MCU core receives a new write command, determine whether there is a stripe parity write command in the received command set;

[0009] (3) if there is no stripe parity write command in the command set, no special processing is required;

[0010] (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, pause writing the current pending stripe parity write command;

[0011] (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 pending stripe parity data.

[0012] Further, the preceding data and parity data within each stripe are in order.

[0013] Further, the method for step (4) to determine whether other stripes have a deadlock conflict with the current stripe parity write command is:

[0014] Check the write status of all stripe commands of the current MCU core, and mark the stripe with an uncompleted write command as a suspicious stripe;

[0015] When the MCU core receives a new write command belonging to the suspicious stripe and the command is not a stripe parity write, cancel the suspicious stripe mark and restore it to a normal stripe;

[0016] When all other stripes are normal stripes, it is considered that there is no deadlock conflict between other stripes and the pending stripe parity write command.

[0017] Further, determining whether a stripe has an uncompleted write command includes the following steps:

[0018] After each MCU core receives a new write command message, if it is not a stripe parity write, according to the XORENGINE number N in the command, operate the ENG N command count corresponding to the MCU context stripe;

[0019] Each MCU core checks the hardware result to determine whether the write command is completed, and if it is not a stripe pairty write, according to the XOR ENGINE number in the command, operates the ENG N command count corresponding to the MCU context stripe;

[0020] After the strip command count is decremented by one, if the count has been reduced to 0, then the strip has no pending write commands, otherwise there are pending write commands.

[0021] Further, the number of bitmap positions of the to-be-processed strip parity corresponds to the respective strip XOR ENGINE number, the current MCU all strip command counts are checked, the strip XOR ENGINE numbers with non-zero counts are obtained, and the bit positions corresponding to the XOR ENGINE numbers of the to-be-processed strip parity bitmap are marked as 1, so as to mark how many other strips have pending write commands before the current to-be-processed parity write.

[0022] After the strip command count is decremented by one, if the count has been reduced to 0, then the strip has no pending write commands, otherwise there are pending write commands.

[0023] When the bitmap of the to-be-processed strip parity write has been completely cleared to 0, the to-be-processed strip parity data is written.

[0024] Further, after the current to-be-processed strip parity write command is suspended, the strip parity write command is added to the core parity write pending list; when it is necessary to continue to write, the command is taken from the core parity write pending list, and the strip parity write command is issued to the hardware to perform parity write operation.

[0025] The present application has the following advantages:

[0026] Through the method described in the present application, the multi-channel write command issuing logic can be simplified, the multi-strip deadlock problem can be solved, and only the commands need to be counted and rearranged in a single core, without additional inter-core synchronization overhead, so that the efficiency and performance are improved. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 A strip normal data write process in the prior art is shown in the figure;

[0028] Figure 2 A strip parity data write process in the prior art is shown in the figure;

[0029] Figure 3 A two-strip parallel operation interlocking in the prior art is shown in the figure;

[0030] Figure 4 A structure of the present application is shown in the figure. DETAILED DESCRIPTION

[0031] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.

[0032] The embodiment proposes a method for RAID multi-strip parallel writing, and the specific process is as follows.

[0033] The command is sent to the MCU core. Since the order is preserved inside each strip, for example, the strip data {D1, D2…Dn, Dp}, after the data is distributed to each MCU core, the order-preserved subset is also received by each MCU core, for example, the received subset can be {Dn’, Dp} or {Dn’}, Dn’ ∈Dn. Since the data in the strip is order-preserved, {Dn’, Dp} or {Dn’} is still order-preserved.

[0034] When there are multiple strips, such as A strip {A1, A2…An, Ap} and B strip {B1, B2…Bn, Bp} 2 strips, the order is preserved before being distributed to multiple MCUs. When n is the same, An is earlier than Bn; when n < n’, An is earlier than An’.

[0035] After the MCU core receives a new write command, it is determined whether there is a strip parity write command in the received command set:

[0036] If there is no strip parity write command in the command set, that is, there is no Ap, Bp, no special processing is required and no deadlock will occur.

[0037] If Ap and Bp exist in the command set and need to be written to the same lun, since the data is order-preserved, it is proved that the previous data of the A strip and the B strip has been written, and no special processing is required and no deadlock will occur.

[0038] If there is Ap, and there is also Bn’ in the same lun, if the MCU has received the write of the B strip before Ap, it means that Bp may be earlier than Ap, and the Ap write needs to be blocked and wait for Bn’ to be written first. If the MCU receives a new B strip write 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. By the following operation, deadlock can be avoided, and the architecture is referred to Figure 4 .

[0039] Step 1. If it is not a strip parity write, the context strip ENG N command count of the MCU is increased by one according to the XOR ENGINE number N in the command after each MCU core receives a new write command message.

[0040] Step 2. After each MCU core checks the hardware result and determines that the write command is completed, if it is not a strip pairty write, the context strip ENG N command count of the MCU is reduced by one according to the XOR ENGINE number in the command.

[0041] Step three, after each MCU core receives a new write command message, if it is a stripe parity write, check all the stripe command counts of this MCU, if it is not zero, then change the corresponding bit position of the parity bitmap to 1 by XOR ENGINE, to mark how many other stripes exist unfinished write commands before this parity write, and then add this stripe parity write command to the parity write pending list of this core.

[0042] Step four, after each MCU core receives a new write command message, if it is not a stripe parity write, then operate the bitmap of each parity write in the parity write pending list of this core, according to the XOR ENGINE number in the command, clear the corresponding bit position of the XOR ENGINE number to 0.

[0043] Step five, after the stripe command count is reduced by one in step two, if the count has been reduced to 0, then according to the XOR ENGINE number in the command, operate the bitmap of each parity write in the parity write pending list of this core, clear the corresponding bit position of the XOR ENGINE number to 0.

[0044] Step six, when the bitmap of a certain parity write has been completely cleared to 0, take off this command from the parity write pending list of this core, and issue the parity write to the hardware for parity write operation.

[0045] Finally, it should be noted that: the above only for the preferred embodiments of the present application, and not for limiting the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application, should be included in the protection scope of the present application.

Claims

1. A method for RAID multi-stripe parallel writing, characterized in that, The method comprises the following steps: (1) issuing a command to an MCU core; (2) determining whether a strip parity write command exists in a received command set after each MCU core receives a new write command; (3) if no strip parity write command exists in the command set, no special processing is required; (4) if a strip parity write command exists in the command set, determining whether other strips have a deadlock conflict with the current to-be-processed strip parity write command, and if a deadlock conflict exists, suspending the writing of the current to-be-processed strip parity write command; (5) if all the previous data of the strip where the current parity write command is located have been written, and no deadlock conflict exists between other strips and the current strip parity write command, writing the to-be-processed strip parity data. The method for determining whether other strips have a deadlock conflict with the current strip parity write command in step (4) is as follows: checking the write conditions of all the strip commands of the current MCU core, and marking a strip where an unfinished write command exists as a suspicious strip; when the MCU core receives a new write command belonging to the suspicious strip and the command is not a strip parity write, canceling the suspicious strip mark and restoring the suspicious strip to a normal strip; when all the other strips are normal strips, it is considered that no deadlock conflict exists between the other strips and the to-be-processed strip parity write command. The method for determining whether a strip has an unfinished write command comprises the following steps: after each MCU core receives a new write command message, if the command is not a strip parity write, adding one to the ENG N command count corresponding to the context strip of the MCU according to the XORENGINE number N in the command; after each MCU core checks the hardware result and determines that the write command is completed, if the command is not a strip parity write, subtracting one from the ENG N command count corresponding to the context strip of the MCU according to the XORENGINE number in the command; after the ENG N command count is subtracted by one, if the count has been reduced to zero, the strip has no unfinished write command, otherwise, the strip has an unfinished write command.

2. The method for RAID multi-stripe parallel writing according to claim 1, wherein, The previous data and the parity data in each strip are in order.

3. The method for RAID multi-stripe parallel writing according to claim 1, wherein, The number of bit positions of the to-be-processed strip parity is corresponding to the XORENGINE number of each strip, the command counts of all the strips of the current MCU are checked, the XORENGINE numbers of the strips with a non-zero count are obtained, and the bit positions corresponding to the XORENGINE numbers of the to-be-processed strip parity bitmap are set to one, so as to mark how many other strips have an unfinished write command before the to-be-processed parity write; after the ENG N command count is subtracted by one, if the count has been reduced to zero, the corresponding bit is cleared to zero according to the XORENGINE number; when the bitmap of the to-be-processed strip parity has been completely cleared to zero, the to-be-processed strip parity data is written.

4. The method for RAID multi-stripe parallel writing according to any one of claims 1-3, characterized in that, After the current pending stripe parity write command is paused, the stripe parity write command is added to the core parity write pending list; when the writing needs to be continued, the command is taken from the core parity write pending list, and the stripe parity write command is issued to the hardware for parity write operation.

Images