CN114265797B

CN114265797B - Storage access control device, hard disk device and method

Info

Publication number: CN114265797B
Application number: CN202111452416.3A
Authority: CN
Inventors: 曾伟; 霍文捷
Original assignee: Hangzhou Haikang Storage Technology Co ltd
Current assignee: Hangzhou Haikang Storage Technology Co ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2024-02-27
Anticipated expiration: 2041-12-01
Also published as: CN114265797A

Abstract

The application provides a storage access control device, a hard disk device and a method. In the application, by disposing a storage access control device between the DDR controller and the system bus in the SSD controller, SSD firmware organizes a DDR request before accessing the L2P table and reaches the storage access control device before the DDR request reaches the DDR controller, the storage access control device detects whether access conflicts of different SSD firmware to the L2P table occur, and once the access conflicts of the L2P table are detected, the DDR request to be processed at present is suspended (i.e. processing is suspended), thus obviously avoiding the access conflicts of the L2P table and preventing the access speed of the L2P table from being influenced by the access conflicts of the L2P table.

Description

Storage access control device, hard disk device and method

Technical Field

The present invention relates to data security technologies, and in particular, to a storage access control device, a hard disk device, and a method.

Background

Currently, for storage devices such as Solid-State Disk (SSD), when firmware therein needs to access an address mapping (L2P: logic address to Physical address) Table (Table), a Double-Rate synchronous dynamic random access memory (DDR: double Data Rate) memory address in the L2P Table to be accessed is directly sent to a DDR controller for access processing, for example, the DDR controller performs operations such as reading and writing on Data corresponding to the DDR memory address (L2P entry in the L2P Table recorded in the DDR memory address). Here, the firmware refers to embedded software or the like running on a CPU core in a storage device such as an SSD, and for example, the firmware applied to the SSD may be denoted as SSD firmware.

In application, different firmware often requires the DDR controller to access the same DDR memory address in the L2P table, which may cause an L2P table access conflict. And the access conflict of the L2P table can affect the access speed of the L2P table.

Disclosure of Invention

The application provides a storage access control device and a storage access control method, so that L2P table access is prevented from being influenced by L2P table access conflict.

The embodiment of the application provides a storage access control device which is deployed between a double rate synchronous dynamic random access memory DDR controller and a system bus in a solid state storage disk SSD controller;

the device comprises at least:

the conflict detection module is used for obtaining a target DDR request sent by SSD firmware to be processed currently, detecting whether a target DDR memory address carried by the target DDR request conflicts with a current DDR memory address currently being accessed in an address mapping L2P table, if so, suspending the target DDR request, and sending an access notification to the processing module when the conflict is detected to disappear; or if not, sending an access notification to the processing module;

the processing module is configured to trigger, according to the access notification from the conflict detection module, the DDR controller to execute, according to a target operation instruction carried by the target DDR request, a target operation corresponding to the target operation instruction on target data corresponding to the target DDR memory address in the L2P table, and generate, after the DDR controller has executed the target operation, a target DDR response corresponding to the target DDR request to obtain the target DDR response by the SSD firmware.

The embodiment of the application also provides a storage access control method, which is applied to a storage access control device between a double rate synchronous dynamic random access memory DDR controller and a system bus, wherein the DDR controller is deployed in a solid state storage disk SSD controller, and the method comprises the following steps:

obtaining a target DDR request sent by SSD firmware to be processed currently;

detecting whether a conflict occurs between a target DDR memory address carried by a target DDR request and a current DDR memory address currently being accessed in an address mapping L2P table, if so, suspending the target DDR request until the conflict disappears;

when the conflict disappears or the target DDR memory address is not in conflict with the current DDR memory address currently being accessed in the L2P table, triggering the DDR controller to execute target operation corresponding to the target operation instruction on target data corresponding to the target DDR memory address in the L2P table according to the target operation instruction carried by the target DDR request, and generating target DDR response corresponding to the target DDR request after the DDR controller executes the target operation so as to obtain the target DDR response by the SSD firmware.

The embodiment of the application also provides a hard disk device, which at least comprises: solid state storage disk SSD controller;

the SSD controller comprises at least a double rate synchronous dynamic random memory DDR controller, a system bus, and a memory access control device disposed between the DDR controller and the system bus, the memory access control device comprising at least the structure described above.

According to the technical scheme, in the application, by disposing a storage access control device between the DDR controller and the system bus in the SSD controller, SSD firmware firstly organizes a DDR request when accessing the L2P table and firstly reaches the storage access control device before the DDR request reaches the DDR controller, the storage access control device detects whether access conflicts of different SSD firmware to the L2P table occur or not, and once the access conflicts of the L2P table are detected, the DDR request to be processed at present is suspended (namely, processing is suspended), so that the access conflicts of the L2P table are obviously avoided, and the access speed of the L2P table is prevented from being influenced by the access conflicts of the L2P table;

further, in this embodiment, the target DDR request may include at least one DDR request at the same time, which may enable the DDR controller to perform an aggregation operation on a plurality of different DDR requests, thereby improving the speed of access to the L2P table.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1 is a schematic structural diagram of an SSD controller according to an embodiment of the disclosure;

fig. 2 is a schematic structural diagram of a memory access control device according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of another memory access control device according to an embodiment of the present application;

FIG. 4 is a flow chart of a method provided in an embodiment of the present application;

fig. 5 is a structural diagram of a hard disk device according to an embodiment of the present application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.

The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

In order to better understand the technical solutions provided by the embodiments of the present application and make the above objects, features and advantages of the embodiments of the present application more obvious, the technical solutions in the embodiments of the present application are described in further detail below with reference to the accompanying drawings.

In the SSD controller, the DDR controller passively performs access operations such as reading and writing based on the instruction of the SSD firmware, and the DDR controller does not make any decision for the L2P access fixed to the SSD, such as deciding whether an L2P access conflict occurs. Based on this, in order to avoid the L2P table access conflict, the embodiment of the present application proposes to deploy a memory access control device between the DDR controller and the system bus in the SSD controller on the premise of maintaining the existing functions of the original module in the SSD controller, such as the DDR controller. That is, the memory access control device is connected to both the system bus and the DDR controller. Alternatively, the system bus herein refers to an information transfer bus in the SSD controller. By disposing the above-mentioned storage access control device between the DDR controller in the SSD controller and the information transmission bus in the SSD controller, i.e. the system bus, access to the L2P table by the SSD firmware may reach the above-mentioned storage access control device before reaching the DDR controller, and the storage access control device detects whether access conflicts of different SSD firmware to the L2P table occur, which will be described in detail below, and will not be repeated here.

Fig. 1 shows, by way of example, a structure in which a memory access control device is disposed between a DDR controller in an SSD controller and a system bus. In the following, the description will be focused on the storage access control device, and other modules in the SSD controller, such as a high-speed serial computer expansion bus (PCIe: peripheral Component Interconnect express) physical layer (PHY) interface for accessing a host, a Security module (Security), a nonvolatile memory interface specification (NVME: non-Volatile Memory Express), a low density parity check code (LDPC: low Density Parity Check Code) check, nonvolatile storage (Nand: not and) management, a disk array (RAID: redundant Arrays of Independent Disks), and the like, which are similar to the prior art, will Not be described again.

The storage access control apparatus described above is described below:

referring to fig. 2, fig. 2 is a block diagram of a storage access control device according to an embodiment of the present application. Alternatively, the storage access control device herein may preferably be a hardware device implemented by hardware, as compared to SSD firmware currently implemented by software. As shown in fig. 2, the storage access control device (denoted as device 200) includes at least:

the conflict detection module 201 is configured to obtain a target DDR request sent from the SSD firmware to be currently processed, detect whether a conflict occurs between a target DDR memory address carried by the target DDR request and a current DDR memory address currently being accessed in the L2P table, suspend the target DDR request if the conflict occurs, and send an access notification to the processing module 202 when the conflict is detected to disappear, or send an access notification to the processing module 202 if the conflict does not occur. Here, the target DDR request is used to access the L2P table, which will be described below based on different scenarios, and will not be described here again.

The processing module 202 is configured to trigger the DDR controller to execute a target operation corresponding to the target operation instruction on target data corresponding to the target DDR memory address in the L2P table according to the target operation instruction carried by the target DDR request according to the notification from the conflict detection module 201, and generate a target DDR response corresponding to the target DDR request after the DDR controller completes the target operation, so as to obtain the target DDR response by the SSD firmware. Here, the target DDR response is generated after the DDR controller performs the target operation, and reflects the result of the DDR controller performing the target operation, for example, the target DDR response reflects the result corresponding to the target operation when the target operation is successfully performed (the result in this case depends on the target operation, for example, the target operation is read, and the result at this time includes at least the read data), or reflects the result when the target operation is failed to be performed (for example, the operation fails), and the corresponding DDR response will be described in detail based on different target DDR requests, which will not be described herein.

As can be seen from fig. 2, in this embodiment, by disposing a storage access control device between the DDR controller and the system bus in the SSD controller, once the SSD firmware organizes a DDR request when it needs to access the L2P table and reaches the storage access control device before the DDR request reaches the DDR controller, the storage access control device detects whether access of different SSD firmware to the L2P table has a conflict, and once the L2P table access conflict is detected, the currently pending DDR request is suspended (i.e. suspension processing), which obviously avoids the L2P table access conflict, and prevents the access speed of the L2P table from being affected by the L2P table access conflict.

In this embodiment, in order to facilitate management of DDR requests initiated by SSD firmware on different CPU cores when accessing the L2P table, optionally, on the basis of the structure shown in fig. 2, as shown in fig. 3, the apparatus 200 may further include: the sequence management module 203.

Wherein, the sequence management module 203 is configured to manage at least one DDR request Sequence (SQ).

In this embodiment, each SQ comprises: at least one DDR request.

In one example, the target DDR request may include at least one DDR request in one of the SQs managed by sequence management module 203.

In this embodiment, the sequence management module 203 is further configured to manage at least one DDR response sequence (CQ). Optionally, in this embodiment, the processing module 202 may further store the target DDR response into one of the CQs managed by the sequence management module 203 after generating the target DDR response.

Alternatively, in this embodiment, the number of SQs and the number of CQs managed by the sequence management module 203 are both related to the number of CPU cores in the SSD controller, and each CPU core should be at least one SQ and at least one CQ. For example, if there are 4 CPU cores in the SSD controller, the sequence management module 203 manages 4 SQs and 4 CQs, where each CPU core corresponds to one SQ and one CQ, respectively.

Optionally, in this embodiment, each SQ stores DDR requests sent by SSD firmware running on its corresponding CPU core, and each CQ stores DDR responses for sending to SSD firmware running on its corresponding CPU core. That is, the same SQ stores DDR requests sent by SSD firmware running on the same CPU core, and the same CQ stores DDR responses sent to SSD firmware running on the same CPU core.

In this case, the processing module 202 may further store the target DDR response in the CQ corresponding to the CPU core in which the SSD firmware that sent the target DDR request is located, managed by the sequence management module 203, after generating the target DDR response.

Alternatively, in the present embodiment, after the target DDR response is stored to the CQ, the processing module 202 may notify the SSD firmware to obtain the target DDR response by means of an interrupt, so that the SSD firmware finally obtains the target DDR response. Of course, as another embodiment, a corresponding status register may be set in advance for each SSD firmware, and initially, the status register set by each SSD firmware is an initial value, for example, 0, where the initial value, for example, 0 indicates that there is no response corresponding to the SSD firmware (i.e., the SSD firmware does not need to obtain its corresponding DDR response). After storing the target DDR response to be sent to the SSD firmware to the CQ, the state setting may be performed with respect to the state register corresponding to the SSD firmware (for example, the initial value of the state register is modified to a specified value such as 1), so that the SSD firmware determines that the DDR response needs to be acquired based on the setting of the state register. When the SSD firmware judges that the corresponding state register is set, the target DDR response sent to the SSD firmware is obtained from the CQ corresponding to the CPU core where the SSD firmware is located, and therefore the target DDR response obtained by the SSD firmware is finally achieved.

As described above, in this embodiment, the SSD firmware on different CPU cores may have a need for accessing the L2P table, so as to facilitate scheduling DDR requests initiated by the SSD firmware on different CPU cores when accessing the L2P table, on the basis of the structure shown in fig. 2, as shown in fig. 3, the apparatus 200 may further include: a scheduling module 204.

The scheduling module 204 is configured to schedule a target SQ from all the SQs managed by the sequence management module 203, determine at least one DDR request currently to be processed from the target SQ as a target DDR request, and notify the conflict detection module 201 to obtain the target DDR request from the target SQ. Optionally, to facilitate the conflict detection module 201 obtaining the target DDR request from the target SQ, the notification herein may carry an identification of the target SQ, as well as location information of the target DDR request in the target SQ. Based on the notification, the final conflict detection module 201 will obtain the target DDR request from the target SQ. How the target SQ is determined will be described below and will not be described in detail here.

Optionally, as an embodiment, when determining that the number of the DDR requests to be currently processed is greater than 1 from the target SQ, the scheduling module 204 checks whether there are at least two DDR requests that satisfy an aggregation condition (such as adjacent DDR memory addresses carried by the condition, etc.) in all the DDR requests to be currently processed, and if so, aggregates the DDR requests that satisfy the aggregation condition together to obtain an aggregate DDR request, that is, aggregate DDR requests, and DDR requests that do not satisfy the aggregation condition together serve as the target DDR requests; if not, the DDR requests which do not meet the aggregation condition are used as the target DDR requests. That is, it is finally achieved that the target DDR request includes at least one DDR request in the target SQ. In this embodiment, the target DDR request includes at least one DDR request (an aggregated DDR request obtained by aggregating each DDR request in the target SQ and/or an unpolymerized DDR request in the target SQ) at the same time, so that the DDR controller can aggregate a plurality of different DDR requests, thereby improving the access speed of the L2P table.

As described above for the target DDR requests, when the number of DDR requests (aggregated DDR requests obtained by aggregating the DDR requests in the target SQ and/or non-aggregated DDR requests in the target SQ) included in the target DDR requests is greater than 1, the scheduling module 204 may further continue to schedule the execution order of the DDR requests in the target DDR requests, and further send the execution order to the conflict detection module 201 in the notification. Based on this, the conflict detection module 201 obtains the above-described execution order from the received notification, and sequentially obtains each DDR request in the target DDR requests from the above-described target SQ in accordance with the execution order, that is, finally obtains the target DDR request.

It should be noted that, when the target DDR request includes different DDR requests executed according to the execution sequence, the conflict detection module may sequentially execute the above conflict detection on each DDR request according to the execution sequence, and once it is detected that there is a conflict between the DDR memory address carried by the DDR request and the DDR memory address currently being accessed in the L2P table, suspend the DDR request, and suspend other DDR requests whose execution sequence is subsequent to the DDR request. Of course, when the conflict disappears or the conflict is detected to be absent, an access notification is sent to the processing module 202 for the DDR request, so as to trigger the DDR controller to execute a corresponding operation on data corresponding to the DDR memory address in the L2P table carried by the DDR request according to an operation instruction carried by the DDR request, and notify the conflict detection module 201 to continue to perform conflict detection on a next DDR request after the DDR request according to an execution sequence after the DDR controller completes the operation, and so on until all DDR requests in the target DDR request are executed to perform conflict detection.

In this embodiment, each SQ is set with a corresponding Weight (Weight). Here, the weight of each SQ to be set may be set according to actual requirements, or may be set according to the operation capability of the CPU core to which it corresponds, etc., and the embodiment is not particularly limited.

Based on this, alternatively, in the present embodiment, the scheduling module 204 may schedule the above-described target SQ from all SQs managed by the sequence management module 203 based on the weight set for each SQ.

Optionally, the scheduling module 204 schedules the target SQ satisfying the setting condition according to the weights set by all SQs managed by the sequence management module 203.

In one example, the setting conditions include at least: the number of DDR requests is greater than a set number threshold, and/or the weight is greater than a set weight condition (e.g., weight maximum, etc.), the present embodiment is not particularly limited. Alternatively, in the present embodiment, the set number threshold may be set according to actual requirements, such as 1, etc., and the present embodiment is not particularly limited. As for the weight being larger than the set weight condition, there are many implementation forms, such as the maximum weight, etc., in the specific implementation, and the present embodiment is not particularly limited.

In this embodiment, the target DDR request is one of instruction requests provided to SSD firmware by the device 200. In an application, the apparatus 200 may provide multiple request instructions to the SSD firmware in combination with the scenario requirements of the SSD firmware for L2P table access.

For example, when the SSD firmware accesses the L2P table after receiving the Host (Host) write data and splitting the Host write data into data units (AU), the corresponding request instruction is Read and force lock (Read & ForceLock). If the target DDR request is used to indicate Read & ForceLock, the target operation instruction is Read & ForceLock operation instruction, and the target operation is Read & ForceLock, where Read & ForceLock is used to indicate to Read target data (L2P entry on the target DDR memory address) to a specified location, modify target data corresponding to the target DDR memory address according to data to be written (herein, for example, virtual address VBA) carried by the target DDR request, and lock the target DDR memory address. Optionally, in this embodiment, after the target data is read to the designated location, the target data corresponding to the target DDR memory address is modified according to the data to be written carried by the target DDR request, and the target DDR memory address is locked, which means that the operation is successfully performed. Optionally, in this embodiment, modifying the target data corresponding to the target DDR memory address according to the data to be written (herein, for example, the virtual address VBA) carried by the target DDR request may include: and modifying the physical block address (PBA: physical Block Address) in the L2P table entry of the target DDR memory address into the VBA carried by the target DDR request. Here, VBA is a temporary address in a Cache (Cache), which may also be referred to as a virtual address. Optionally, in the present embodiment, after locking the target DDR memory address, the subsequent SSD firmware accesses the locked target DDR memory address when accessing the L2P table based on the following scenario: after data is recycled by a garbage recycling (GC) mode or the number of recycled data reaches a set number and is written into a storage medium (Nand), a situation that the target DDR memory address cannot be accessed because of being locked (i.e., access failure) occurs, particularly, read and weblock (see below), which can preferentially ensure the security of data written into a host.

For another example, when the SSD firmware accesses the L2P table after recovering data by Garbage Collection (GC) or after the number of recovered data reaches a set number and writes to the storage medium (Nand), the corresponding request instruction is Read and lock on force (Read & weblock). If the target DDR request is used for indicating Read & WeakLock, the target operation instruction includes a Read & WeakLock operation instruction, and the target operation is Read & WeakLock. Here, read & weblock is used for indicating and judging whether the target DDR memory address is locked, if yes, the operation fails, otherwise, the target data is Read to the designated location, and the target data corresponding to the target DDR memory address is modified according to the data to be written carried by the target DDR request. Optionally, in this embodiment, after the reading of the target data to the designated location is completed, the modifying the target data corresponding to the target DDR memory address according to the data to be written carried by the target DDR request means that the Read & weblock operation is successful. In this embodiment, the modification of the target data corresponding to the target DDR memory address according to the data to be written carried by the target DDR request is described above, which is not repeated herein.

For another example, when the SSD firmware accesses the L2P table after the data amount of the host write data reaches the preset amount and is written to the storage medium, the corresponding request instruction is Read and conditional write (conditional write). If the target DDR request is used for indicating Read & Condition write, the target operation instruction includes a Read & Condition write operation instruction, where the target operation is Read & Condition write, and Read & Condition write is used for indicating reading the target data to a specified location, and when it is determined that the target data includes VBA carried by the target DDR request (e.g., PBA in the target data is the same as VBA carried by the target DDR request), the target data corresponding to the target DDR memory address is modified according to the data to be written carried by the DDR request, which means that the operation is successful at this time, otherwise, the return operation fails. Here, the data to be written carried by the DDR request is PBA, and based on this, modifying the target data corresponding to the target DDR memory address according to the data to be written carried by the DDR request may specifically be: and modifying the PBA in the L2P table entry on the target DDR memory address to VBA carried by the DDR request. It should be noted that, in this embodiment, if it is found that the target DDR memory address carried by the target DDR request is currently locked before the target data is read to the designated location, then the target DDR memory address may be unlocked at this time.

For another example, when the SSD firmware receives a scenario that the host reads to access the L2P table, the corresponding request instruction is a Read operation (Read). If the target DDR request is to indicate a Read, the target operation instruction includes a Read instruction, and the target operation is a Read. Here, read is used to indicate that the target data (L2P entry at the target DDR memory address) is Read.

For another example, when the PBA read by the SSD firmware after accessing the L2P table based on the host read operation has an uncorrectable (unec) read error, the corresponding request instruction is a Write operation (Write). The read errors here may be errors that are uncorrectable by error correction codes (ECC: error Correcting Code) such as hard-coded, soft-coded, etc. If the target DDR request indicates Write, the target operation instruction includes a Write instruction, and the target operation is Write. Here, the Write is used to indicate that the target data corresponding to the target DDR memory address is modified according to the data to be written carried by the target DDR request, for example, the PBA in the L2P entry on the target DDR memory address is modified to the data to be written carried by the target DDR request, such as the PBA or the specific value.

The target DDR request is described above by way of example.

Alternatively, if the target DDR request is used to indicate Read & ForceLock. The target DDR response carries at least the target data stored at the specified location, and a Read & ForceLock success identification (Read & ForceLock execution is typically successful in an application). Alternatively, the target DDR response may include an Old data field (Old Value), where the Old Value carries the target data.

Optionally, if the target DDR request is used to indicate Read & weblock, correspondingly, the target DDR response carries at least a Read & weblock failure identifier once Read & weblock execution fails. And once the Read & WeakLock is successfully executed, the target DDR response carries at least the target data stored in the designated location and a Read & WeakLock success identification. As above, the target DDR response will carry the target data through the Old Value.

Optionally, if the target DDR request is used to indicate Read & Condition write, correspondingly, once Read & Condition write fails, the target DDR response may carry a Read & Condition write failure identifier, or may carry target data and a Read & Condition write failure identifier at the same time, and once Read & Condition write succeeds, the target DDR response carries at least the target data stored in the specified location and the Read & Condition write success identifier. Similarly, the target DDR response will carry the target data through the Old Value.

Alternatively, if the target DDR request is used to indicate Read, the target DDR response carries at least the Read target data and the Read success status identifier (in application, read is generally successful).

Alternatively, if the target DDR request is used to indicate a Write, the target DDR response carries at least a Write success status identifier correspondingly (in applications, write is generally successful).

In this embodiment, in order to distinguish between different DDR requests, there is a unique request identifier (TAG) for identifying the DDR request in each DDR request. Based on the request, the target DDR request carries a request identifier for identifying the target DDR request; correspondingly, the target DDR response also carries the request identifier, so as to indicate which DDR request the target DDR response is for.

The apparatus provided in the embodiments of the present application is described above. The embodiment of the application also provides a method corresponding to the device. Referring to fig. 4, fig. 4 is a block diagram of a method provided in an embodiment of the present application. The method is applied to the storage access control device. As shown in fig. 4, the method may include:

step 401, obtaining a target DDR request from SSD firmware to be currently processed.

Step 402, detecting whether a conflict occurs between a target DDR memory address carried by the target DDR request and a current DDR memory address currently being accessed in an address mapping L2P table, and if so, suspending the target DDR request until the conflict disappears.

Step 403, triggering the DDR controller to execute the target operation corresponding to the target operation instruction on the target data corresponding to the target DDR memory address in the L2P table according to the target operation instruction carried by the target DDR request when the conflict disappears or the target DDR memory address does not conflict with the current DDR memory address currently being accessed in the L2P table, and generating the target DDR response corresponding to the target DDR request after the DDR controller completes the target operation, so as to obtain the target DDR response by the SSD firmware.

As can be seen from the flow shown in fig. 4, in this embodiment, by disposing the above-mentioned storage access control device between the DDR controller and the system bus in the SSD controller, once the SSD firmware organizes a DDR request before it needs to access the L2P table and reaches the above-mentioned storage access control device before the DDR request reaches the DDR controller, the storage access control device detects whether the access of different SSD firmware to the L2P table conflicts, and once the L2P table access conflict is detected, the currently pending DDR request is suspended (i.e. the processing is suspended), which obviously avoids the L2P table access conflict, and prevents the access speed of the L2P table from being affected by the L2P table access conflict.

Optionally, in step 401 above, obtaining the target DDR request sent from the SSD firmware to be currently processed may include:

scheduling a target SQ from all recorded SQs;

and determining at least one DDR request to be processed currently from the target SQ as a target DDR request.

In this embodiment, each SQ includes at least one DDR request. Each SQ is set with a corresponding weight. Based on this, the above-mentioned scheduling of target SQs from all SQs already recorded may include: dispatching out target SQ meeting the set condition according to the set weight of each SQ; the setting conditions at least comprise: the number of DDR requests is greater than a set number threshold and the weight satisfies a set weight condition (e.g., maximum weight, etc.).

Alternatively, in this embodiment, the number of SQs is related to the number of CPU cores in the SSD controller, at least one SQ per CPU core. Each SQ stores DDR requests sent by SSD firmware running on its corresponding CPU core.

Alternatively, in the present embodiment, the targeted DDR response may be further deposited into one of the CQs after the targeted DDR response is generated. Here, the number of CQs is related to the number of CPU cores in the SSD controller, and each CPU core should be at least one CQ. Each CQ stores DDR responses for sending to SSD firmware running on its corresponding CPU core. Based on this, the target DDR response can be stored in the CQ corresponding to the CPU core in which the SSD firmware is located. The SSD firmware may then be notified by way of an interrupt to obtain the target DDR response, such that the SSD firmware eventually obtains the target DDR response. Of course, as another embodiment, a corresponding status register may be set in advance for each SSD firmware, and after storing the target DDR response to be sent to the SSD firmware into the CQ, the corresponding status register may be set for the SSD firmware (specifically described above). Then, the SSD firmware can find that the corresponding status register is set, and then judge that the DDR response needs to be acquired, namely acquire the DDR response from the CQ corresponding to the CPU core, and finally achieve the DDR firmware acquiring target DDR response.

As one embodiment, the target DDR request is used for indicating a Read & force lock (Read & force lock), the target operation instruction includes a Read & force lock operation instruction, the target operation is a Read & force lock operation, the Read & force lock operation is used for indicating to Read the target data to a designated location, modifying the target data corresponding to the target memory address according to the data to be written carried by the target DDR request, and locking the target memory address. This means that the read and force lock operations are successful.

Correspondingly, the target DDR response at least carries the target data stored in the designated position and a successful identification of the read and forced locking operation.

As one embodiment, the target DDR request is used for indicating a Read and non-forced locking operation and the weblock is used for indicating a Read and non-forced locking operation, the target operation includes a Read and non-forced locking operation, the Read and non-forced locking operation is used for indicating and judging whether the target memory address is locked, if yes, the operation fails, otherwise, the target data is Read to a designated location, and the target data corresponding to the target memory address is modified according to the data to be written carried by the target DDR request, which means that the Read and non-forced locking operation is successful.

Correspondingly, the target DDR response carries an operation failure identifier when the read and non-forced locking operation fails, or carries the target data stored in the designated position and an operation success identifier when the read and non-forced locking operation succeeds.

As one embodiment, the target DDR request is used for indicating a Read and conditional write operation and a conditional write operation, the target operation instruction includes a Read and conditional write operation instruction, the target operation is a Read and conditional write operation, the Read and conditional write operation is used for indicating to Read the target data to a designated location, and when it is determined that the target data includes the cache virtual address VBA carried by the target DDR request, the target data corresponding to the target memory address is modified according to the data to be written carried by the DDR request, which means that the Read and conditional write operation is successful, otherwise, the return operation fails.

Correspondingly, the target DDR response can carry an operation failure identifier when the read and conditional write operations fail, can also carry target data and an operation failure identifier at the same time, or can carry the target data stored in the designated position and an operation success identifier when the read and conditional write operations succeed.

As one embodiment, the target DDR request is to indicate a Read operation Read, the target operation instruction includes a Read operation instruction, the target operation is a Read operation, and the Read operation is to indicate to Read the target data; and the target DDR response carries the read target data and the read success state identification.

As one embodiment, the target DDR request is configured to indicate a Write operation Write, where the target operation instruction includes a Write operation instruction, where the target operation is a Write operation, and the Write operation is configured to indicate to modify target data corresponding to the target memory address according to data to be written carried by the target DDR request; and the target DDR response carries a writing operation success identifier.

In this embodiment, the target DDR request is one of the request instructions provided to the SSD firmware. Wherein, different application scenes correspond to different request instructions.

Optionally, when the SSD firmware accesses the L2P table after splitting the received host write data into data units AU, a DDR request is sent indicating Read and force lock Read & ForceLock.

When SSD firmware accesses the L2P table after data is reclaimed by garbage collection GC or after the amount of reclaimed data has reached a set amount and written to the storage medium, DDR requests are sent indicating Read and non-forced lock Read & WeakLock.

When the SSD firmware accesses the L2P table after the data amount reaches a preset amount of host write data is written, DDR requests for indicating Read and conditional write Read & Condition Write are sent.

When SSD firmware receives a host Read operation access L2P table, sending a DDR request for indicating a Read operation Read; when the SSD firmware accesses the L2P table upon receiving a host Read operation, a DDR request is sent indicating a Read operation Read.

When the read error UNECC occurs in the read PBA after the SSD firmware accesses the L2P table based on the host read operation, a DDR request is sent indicating a Write operation Write.

In this embodiment, the target DDR request carries a request identifier TAG for identifying the target DDR request, where the request identifier is used to distinguish DDR requests, and different DDR requests carry different request identifiers; the target DDR response carries the request identification.

The memory access control device may have the following hardware configuration. Referring to fig. 5, fig. 5 is a structural diagram of a hard disk device provided in an embodiment of the present application. As shown in fig. 5, the hard disk device structure may include at least: and an SSD controller. In one example, the SSD controller includes at least: at least one CPU core where SSD firmware is deployed, a DDR controller, a system bus, and a memory access control device deployed between the DDR controller and the system bus. In one example, the memory access control device is shown in FIG. 2.

Based on the same application concept as the above method, the embodiments of the present application further provide a machine-readable storage medium, where a number of computer instructions are stored, where the computer instructions can implement the method disclosed in the above example of the present application when executed by a processor.

By way of example, the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, and the like. For example, a machine-readable storage medium may be: RAM (Radom Access Memory, random access memory), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., hard drive), a solid state drive, any type of storage disk (e.g., optical disk, dvd, etc.), or a similar storage medium, or a combination thereof.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present application.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

Moreover, these computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims

1. A memory access control device, characterized in that the device is disposed between a double rate synchronous dynamic random access memory DDR controller in a solid state memory disk SSD controller and a system bus;

the device comprises at least:

the processing module is used for triggering the DDR controller to execute target operation corresponding to a target DDR memory address in the L2P table according to a target operation instruction carried by the target DDR request according to the access notification from the conflict detection module, and generating a target DDR response corresponding to the target DDR request after the DDR controller executes the target operation so as to obtain the target DDR response by the SSD firmware;

The target DDR request is one of request instructions provided by the device to the SSD firmware, different request instructions correspond to different application scenes, and the target DDR request at least comprises one of the following:

when the SSD firmware accesses the L2P table after splitting the received host write data into data units AU, sending DDR requests for indicating Read and forced locking Read & forceLock;

when SSD firmware accesses an L2P table after recovering data in a garbage collection GC mode or after the data amount of the recovered data reaches a set amount and is written into a storage medium, sending DDR requests for indicating Read and non-forced locking and WeakLock;

when the SSD firmware accesses the L2P table after the data amount reaches the preset amount of host write data is written, sending DDR requests for indicating reading and conditional write Read & Condition Write;

when SSD firmware receives a host Read operation access L2P table, sending a DDR request for indicating a Read operation Read;

when the SSD firmware generates a read error UNECC at a physical block address PBA read after accessing the L2P table based on a host read operation, a DDR request for indicating a Write operation Write is sent.

2. The apparatus of claim 1, wherein the apparatus further comprises:

A sequence management module for managing at least one DDR request sequence SQ and at least one DDR response sequence CQ;

wherein each SQ comprises: at least one DDR request;

the target DDR request comprises at least one DDR request in one of the SQs managed by the sequence management module;

the processing module further stores the target DDR response into one of the CQs managed by the sequence management module after generating the target DDR response.

3. The apparatus of claim 2, wherein the device comprises a plurality of sensors,

the number of the SQs and the number of the CQs managed by the sequence management module are related to the number of CPU cores in the SSD controller, and each CPU core should be at least one SQ and at least one CQ;

each SQ stores DDR requests sent by SSD firmware running on its corresponding CPU core, and each CQ stores DDR responses for sending to SSD firmware running on its corresponding CPU core.

4. The apparatus of claim 2, wherein the apparatus further comprises:

the scheduling module is used for scheduling a target SQ from all the SQs managed by the sequence management module, determining at least one DDR request to be processed currently from the target SQ as the target DDR request, and informing the conflict detection module of acquiring the target DDR request from the target SQ.

5. The apparatus of claim 4, wherein each SQ is set to a corresponding Weight;

the scheduling module schedules out target SQ meeting the set condition according to the set weights of all SQs managed by the sequence management module; the setting conditions at least comprise: the number of DDR requests is greater than a set number threshold and/or the weight satisfies a set weight condition.

6. The apparatus of claim 1, wherein the device comprises a plurality of sensors,

when the target DDR request is used for indicating reading and forced locking and forceLock, the target operation instruction comprises a reading and forced locking operation instruction, the target operation is a reading and forced locking operation, the reading and forced locking operation is used for indicating reading the target data to a designated position, modifying the target data corresponding to the target DDR memory address according to the data to be written carried by the target DDR request, and locking the target DDR memory address; the target DDR response at least carries the target data stored in the designated position and a successful identification of the read and forced locking operation; or,

when the target DDR request is used for indicating a Read and non-forced locking operation and a WeakLock, the target operation instruction comprises a Read and non-forced locking operation instruction, the target operation is a Read and non-forced locking operation, the Read and non-forced locking operation is used for indicating and judging whether the target DDR memory address is locked or not, if yes, the operation fails, and the target DDR response carries an operation failure identifier; or if not, reading the target data to a designated position, and modifying the target data corresponding to the target DDR memory address according to the data to be written carried by the target DDR request, wherein the target DDR response carries the target data stored in the designated position and an operation success identifier; or,

When the target DDR request is used for indicating a Read and conditional write operation and a conditional write operation, the target operation instruction comprises a Read and conditional write operation instruction, the target operation is a Read and conditional write operation, the Read and conditional write operation is used for indicating the target data to be Read to a designated position, and when judging that the target data comprises a cache virtual address VBA carried by the target DDR request, the target data corresponding to the target DDR memory address is modified according to the data to be written carried by the DDR request, and the target DDR response carries the target data stored in the designated position and an operation success identifier; or the operation fails when the target data does not include the cache virtual address VBA carried by the target DDR request, and the target DDR response carries an operation failure identifier; or,

when the target DDR request is used for indicating a Read operation Read, the target operation instruction comprises a Read operation instruction, the target operation is a Read operation, and the Read operation is used for indicating to Read the target data; the target DDR response carries the read target data and the read success state identification; or,

When the target DDR request is used for indicating a Write operation Write, the target operation instruction comprises a Write operation instruction, the target operation is a Write operation, and the Write operation is used for indicating to modify target data corresponding to the target DDR memory address according to data to be written carried by the target DDR request; and the target DDR response carries a writing operation success identifier.

7. The apparatus of claim 1, wherein the target DDR request carries a request identification TAG for identifying the target DDR request, the request identification being for distinguishing DDR requests, different DDR requests carrying different request identifications; the target DDR response carries the request identification.

8. The device according to any one of claims 1 to 7, characterized in that the device is a hardware device implemented in hardware.

9. A memory access control method applied to a memory access control device disposed between a double rate synchronous dynamic random memory DDR controller in a solid state memory disk SSD controller and a system bus, the method comprising:

obtaining a target DDR request sent by SSD firmware to be processed currently;

when the conflict disappears or the target DDR memory address is not in conflict with the current DDR memory address currently being accessed in the L2P table, triggering the DDR controller to execute target operation corresponding to the target operation instruction on target data corresponding to the target DDR memory address in the L2P table according to the target operation instruction carried by the target DDR request, and generating target DDR response corresponding to the target DDR request after the DDR controller executes the target operation so as to obtain the target DDR response by the SSD firmware;

10. The method of claim 9, wherein the target DDR request comprises at least one DDR request in one of a DDR request sequence SQ; each SQ includes at least one DDR request;

wherein the number of SQs is related to the number of CPU cores in the SSD controller, each CPU core should at least one SQ, each SQ stores a DDR request sent by SSD firmware running on its corresponding CPU core.

11. The method according to claim 9 or 10, wherein when the target DDR request is used for indicating a Read & ForceLock operation instruction, the target operation instruction is a Read & ForceLock operation, the Read & ForceLock operation is used for indicating to Read the target data to a specified location, modifying the target data corresponding to the target DDR memory address according to the data to be written carried by the target DDR request, and locking the target DDR memory address; the target DDR response at least carries the target data stored in the designated position and a successful identification of the read and forced locking operation; or,

12. A hard disk device, characterized in that the hard disk device comprises at least: solid state storage disk SSD controller;

the SSD controller includes at least a double rate synchronous dynamic random memory DDR controller, a system bus, and a memory access control device disposed between the DDR controller and the system bus, the memory access control device including at least the structure as in any one of claims 1 to 8.