Memory management method and device, electronic equipment and computer readable medium

Abstract

The invention discloses a memory management method and device, a storage system and a computer readable medium, and relates to the technical field of mobile terminals.The method comprises the steps that under the condition that a current application scene of a host belongs to a specified scene, pre-erasure parameters are determined, the specified scene is used for representing that the data volume corresponding to the to-be-written data is greater than a specified threshold value; pre-erasure parameters are interacted with the memory through a pre-erasure command, and the pre-erasure parameters comprise at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory and the pre-erasure capacity currently configured by the host. Therefore, the pre-erasure parameter can be determined in a scene that a host faces a large amount of data to be written, and the pre-erasure instruction interacts with the memory so as to serve subsequent pre-erasure operation.

Description

Technical Field

[0001] This application relates to the technical field of mobile terminals, and more specifically, to a memory management method, apparatus, storage system, and computer-readable medium. Background Art

[0002] Currently, in flash memory, especially NAND-type flash memory, a pre-erasure operation is usually required. Generally, when such a memory is full in the current block and switches to a new block, the new block needs to be erased first and then data is written. Summary of the Invention

[0003] This application proposes a memory management method, apparatus, storage system, and computer-readable medium to improve the above-mentioned defects.

[0004] In a first aspect, this application provides a memory management method, which is applied to a host of a storage system. The storage system further includes the memory, and the host is connected to the memory. The method includes: when the current application scenario of the host belongs to a specified scenario, determining pre-erasure parameters, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold; interacting with the memory through a pre-erasure command with the pre-erasure parameters, where the pre-erasure parameters include at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host.

[0005] In a second aspect, this application further provides a memory management apparatus, which is applied to a host of a storage system. The storage system further includes the memory, and the host is connected to the memory. The apparatus includes: a determination unit and an interaction unit. The determination unit is configured to determine pre-erasure parameters when the current application scenario of the host belongs to a specified scenario, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold. The interaction unit is configured to interact with the memory through a pre-erasure command with the pre-erasure parameters, where the pre-erasure parameters include at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host.

[0006] In a third aspect, this application further provides a storage system, including: a host; a memory; the host is connected to the memory, and the host is configured to execute the above method.

[0007] In a fourth aspect, this application further provides a computer-readable medium, where the readable storage medium stores program code executable by a processor, and when the program code is executed by the processor, the processor is caused to execute the above method.

[0008] The memory management method, device, storage system, and computer-readable medium provided by this application determine pre-erasure parameters when the current application scenario of the host belongs to a specified scenario, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold; interact with the memory through a pre-erasure command, where the pre-erasure parameters include at least one of the maximum pre-erasure capacity supported by the memory, the remaining pre-erasure capacity of the memory currently, and the pre-erasure capacity currently configured by the host. Therefore, in a scenario where the host faces a large amount of data to be written, pre-erasure parameters can be determined and interacted with the memory through pre-erasure instructions to serve subsequent pre-erasure operations.

[0009] Other features and advantages of this application will be described in the subsequent description, and, in part, will become obvious from the description or will be understood by implementing this application. The objectives and other advantages of this application can be achieved and obtained through the structures specifically pointed out in the written description, claims, and drawings. Brief Description of the Drawings

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of this application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0011] Figure 1 Shows a schematic diagram of the storage system provided by an embodiment of this application;

[0012] Figure 2 Shows a flowchart of the memory management method provided by an embodiment of this application;

[0013] Figure 3 Shows an interaction schematic diagram between the host and the memory of the storage system provided by an embodiment of this application;

[0014] Figure 4 Shows a flowchart of the memory management method provided by another embodiment of this application;

[0015] Figure 5 Shows a schematic diagram of the architecture of the pre-erasure command provided by an embodiment of this application;

[0016] Figure 6 Shows a flowchart of the memory management method provided by yet another embodiment of this application;

[0017] Figure 7 Shows a schematic diagram of the architecture of the mode field provided by an embodiment of this application;

[0018] Figure 8 Shows a schematic diagram of the value taken by the mode field provided in an embodiment of the present application;

[0019] Figure 9 Shows a flowchart of a memory management method provided in another embodiment of the present application;

[0020] Figure 10 Shows a schematic diagram of the operation code provided in an embodiment of the present application;

[0021] Figure 11 Shows a schematic diagram of the bit values of the pre-erasure parameters provided in an embodiment of the present application;

[0022] Figure 12 Shows a flowchart of a memory management method provided in still another embodiment of the present application;

[0023] Figure 13 Shows a schematic diagram of the identifier of the pre-erasure parameters provided in an embodiment of the present application;

[0024] Figure 14 Shows a flowchart of a memory management method provided in still another embodiment of the present application;

[0025] Figure 15 Shows a schematic diagram of the first specified bit provided in an embodiment of the present application;

[0026] Figure 16 Shows a schematic diagram of the first specified bit provided in another embodiment of the present application;

[0027] Figure 17 Shows a schematic diagram of the second specified bit provided in an embodiment of the present application;

[0028] Figure 18 Shows a block diagram of a memory management device provided in an embodiment of the present application;

[0029] Figure 19 Shows a storage unit for storing or carrying program code for implementing the method according to the embodiments of the present application. Detailed implementation manners

[0030] To enable those skilled in the art to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Usually, the components of the embodiments of this application described and illustrated in the accompanying drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents the selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative efforts belong to the scope of protection of this application.

[0031] It should be noted that similar reference numerals and letters denote similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, terms such as "first" and "second" are only used for differential description and cannot be understood as indicating or implying relative importance.

[0032] Currently, in flash memory, especially NAND-type flash memory, a pre-erasure operation usually needs to be performed. Generally, in a host system that uses Universal Flash Storage (UFS) as a storage device, the firmware of UFS manages the medium (NAND flash) in units of virtual blocks (VBs). When the current block of the UFS device is full and switches to a new block, the new block needs to be erased first (in milliseconds), and then data is written (programmed). At the same time, due to the characteristics of Nand Flash, the block medium that has been erased has poor stability and cannot be used for data writing after a long time. Therefore, storage devices usually do not erase a large number of blocks in advance.

[0033] The pre-erase operation means that when a write operation is performed on a flash memory, if the currently selected block is full and no new data can be written, an idle block needs to be selected for writing. Here, an idle block refers to a block where all the data is invalid and can be erased and then used to write new data. Therefore, the selected idle block needs to be erased once before it can be used to write new data. This process is usually managed and executed by the controller. In a NAND-type flash memory, data can only be erased in units of blocks (Blocks). This leads to an operation process called "Erase-Write". The purpose of the pre-erase operation is to erase the selected idle block in advance before the actual write operation is performed, avoiding the write delay caused by the need to perform an erase operation when a block switch occurs during data writing, thereby accelerating the write speed of the memory.

[0034] Due to the characteristics of Nand Flash that it erases before writing, when the write pressure on the UFS device is relatively high, there is always a period of time in milliseconds when it cannot write. Therefore, pre-erasing a part of the blocks and reducing the time taken for block switching in the UFS can significantly improve the write performance of the device and at the same time reduce the maximum delay caused by the erase operation during the block switching process.

[0035] The current pre-erase solutions are generally as follows:

[0036] (1) Autonomous pre-erase when the storage device is idle. In this solution, the storage device erases a certain number of blocks during its idle time according to the set pre-erase capacity threshold. When switching to write to a new block, it preferentially selects the pre-erased blocks. Usually, the capacity threshold is adjustable and will decrease as the number of idle blocks in the device decreases. At the same time, when selecting pre-erased blocks, it preferentially selects the blocks that were pre-erased earlier because these blocks are more likely to have media stability risks.

[0037] (2) Re-erase to ensure the stability of pre-erased blocks. This solution is to re-erase the blocks with deteriorated stability on the premise of the device's autonomous pre-erase solution to ensure the usage stability. Since the pre-erased blocks are automatically replenished by the storage device during idle time and there is no way to predict how long the host will use these blocks, there will be a problem that the host does not write for a long time and the stability of the pre-erased blocks gradually deteriorates, resulting in the inability to write. In this scenario, when the device detects a block with deteriorated stability, it needs to perform another erase. However, the lifespan of the storage medium is limited, and the additional erase will affect the medium lifespan.

[0038] (3) The host notifies the device to perform garbage collection (GC) and erasure on a certain area. This solution is that the host notifies the device to perform garbage collection and erasure operations on a certain area. The host delimits an area (such as several blocks) for the device through a command. After receiving the command, the device will organize the valid data in this area and erase this area for wear leveling and performance optimization. Since the UFS device does not expose the specific physical area usage situation to the host, the relevance of this solution to this solution is limited.

[0039] However, the inventors found in the research that the current pre-erasure solutions usually have the following disadvantages:

[0040] (1) Relatively fixed pre-erasure capacity threshold: In the current device self-pre-erasure solutions, the pre-erasure capacity is determined by the device itself and is pre-erased to the set threshold when idle. To obtain greater performance benefits, the threshold should be expanded as much as possible; but considering stability and the situation of too few free blocks, the threshold cannot be too large. Therefore, the device will choose a threshold that balances benefits and risks. This threshold may change during the device's life cycle, but it is fixed for a period of time and cannot adapt to the changes in the host's write operations. A more ideal situation is to expand the threshold when the host writes frequently and reduce the threshold or even not perform pre-erasure when the host has been writing and is idle.

[0041] (2) Stability risk of pre-erased blocks remaining: Since in the existing solutions, the device cannot know the host's write operations and the pre-erasure threshold is relatively fixed, there will always be some pre-erased blocks in the device. When the host does not write for a period of time, the pre-erased blocks are prone to stability risks. For this reason, in the existing solutions, on the one hand, an additional stability check mechanism for pre-erased blocks is required, and on the other hand, the pre-erased blocks with poor stability are erased again, actually resulting in a waste of the number of erasures.

[0042] Therefore, to overcome the above defects, the embodiments of the present application provide a memory management method that can perform pre-erasure in combination with the current scenario.

[0043] It should be noted that the memory management method provided by the embodiments of the present application is applied to a system composed of a host using a flash memory, such as Figure 1 As shown, the storage system 10 includes a host 100 and a memory 200, and the host 100 is connected to the memory 200. Exemplarily, the host 100 may be an electronic device, and the electronic device may be a device capable of running application programs such as a smart phone, a tablet computer, an e-book, etc. In the embodiments of the present application, the host 100 is a smart phone. The memory 200 may be the above-mentioned flash memory. For example, the memory 200 is a UFS.

[0044] It can be understood that the memory 200 can be an internal memory of the host 100. That is to say, the memory 200 can be integrated onto the motherboard of the host 100 and used as the ROM of the mobile phone to store the operating system, application programs, and user data. Additionally, the memory 200 can be an external memory of the host 100, that is, a peripheral device belonging to the host 100. For example, taking the memory 200 as a UFS, the host 100 is connected to the memory 200 through a USB interface. Of course, the UFS storage device can also be designed in the form of a pluggable memory card, similar to a traditional SD card or microSD card. In this way, the user can insert the UFS storage device into the USB interface of the mobile phone and perform data transmission and access through the USB interface. In the embodiments of the present application, it is not limited whether the memory 200 is an external memory or an internal memory of the host 100, and the host is used to execute the following embodiments.

[0045] Please refer to Figure 2 , this method is applied to the above-mentioned host. For the convenience of description, in the following embodiments, taking the memory as a UFS as an example for description. Of course, the memory can also be of other types, and this is not limited. This method includes: S201 to S202.

[0046] S201: When the current application scenario of the host belongs to a specified scenario, determine a pre-erasure parameter, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold.

[0047] It can be understood that the specified scenario refers to a scenario where there may be a large amount of data to be written. If the current application scenario of the host belongs to the specified scenario, it means that the host is currently in a scenario where a large amount of data will soon be written, that is, a high-pressure writing scenario. Exemplarily, the following method can be used to determine whether the current application scenario of the host belongs to the specified scenario. Therefore, the specified threshold can be a reference value, which is used to distinguish between the method of automatically pre-erasing in the present application and different scenarios where this method is not executed. The specific value of the specified threshold is not limited.

[0048] As an implementation manner, the implementation manner of whether the current application scenario of the host belongs to the specified scenario can be to determine the target application program currently running on the host; if the target application program belongs to a preset application list, it is determined that the current application scenario of the host belongs to the specified scenario, and the current pre-erasure capacity is determined based on the target application program.

[0049] Specifically, taking the host as a smart phone as an example, the running application can be an application running in the foreground and / or background of the smart phone. In the embodiments of the present application, the running application can be an active application. The active application can refer to an application that has run in the foreground during the current time period and is currently running in the foreground or background, or an application that has written data to the memory during the current time period, or an application that is currently running in the foreground, or an application that is currently reading and / or writing data.

[0050] In the embodiments of the present application, the active application refers to an application that is currently running in the foreground of the electronic device. That is to say, the implementation manner of determining the running application of the host is to determine the application that is currently running in the foreground of the host, that is, the application that is currently running in the foreground of the electronic device.

[0051] Exemplarily, the preset application list can be an application program that has a large number of sequential write operations statistically. For example, when a certain game application performs an installation package installation operation or a version update operation, there are a large number of sequential write operations. Among them, a large number of sequential write operations means that the write operation is continuously executed within a preset time period and the amount of written data is greater than the preset data amount. It can be understood that the application programs in the application list can be added manually or determined by the host according to whether there are a large number of sequential write operations for each application program during the statistical period, and the specific method is not limited here.

[0052] Therefore, the preset application list can be regarded as a whitelist corresponding to the application programs with high-pressure writing. After the host determines the running application, the running application is used as the target application, and it is determined whether the target application is in the preset application list. If it is in the preset application list, it is determined that there is an APP in the high-pressure writing whitelist working currently, so as to determine that the current application scenario of the host belongs to the specified scenario. Thus, the host can trigger the memory to perform a pre-erasure operation, and the prerequisite for performing the pre-erasure operation is to determine the pre-erasure parameter and interact with the memory with the pre-erasure parameter.

[0053] As another implementation manner, the implementation manner of whether the current application scenario of the host belongs to the specified scenario can be to determine the application program to be updated by the host currently; if the number of the current application programs to be updated is greater than the specified number, it is determined that the current application scenario of the host belongs to the specified scenario, and the current pre-erasure capacity is determined based on the application program to be updated. That is to say, if the number of application programs to be updated by the host currently is too large, that is, in the scenario where a large number of APPs need to be updated, it can be determined that the current application scenario of the electronic device belongs to the high-pressure writing scenario.

[0054] As another implementation manner, the implementation manner of whether the current application scenario of the host belongs to the specified scenario may be as follows: determine the application program to be updated on the host currently; determine the target object to be downloaded or copied on the host currently; if the capacity of the target object is greater than the specified capacity, determine that the current application scenario of the host belongs to the specified scenario, and determine the current pre-erasure capacity based on the target object. The capacity of the target object can also be understood as the size of the storage space occupied by the target object, that is, the size of the target object. The target object can be a file or an application program, and the capacity of the target object can refer to the size of the application program or the size of the file. It can be understood that the target object is the object to be downloaded currently or the object to be copied currently. Therefore, if the target object to be downloaded currently is greater than the specified capacity, it can be regarded that the host is in the download scenario of a large-capacity APP or a large-capacity file. Similarly, if the target object to be copied currently is greater than the specified capacity, it can be regarded that the host is in the copy scenario of a large-capacity APP or a large-capacity file.

[0055] As yet another implementation manner, the implementation manner of whether the current application scenario of the host belongs to the specified scenario may be as follows: in the case of determining that the host is to perform a data migration operation, if it is determined that the current application scenario of the host belongs to the specified scenario, determine the current pre-erasure capacity based on the data volume corresponding to the data migration operation. Among them, data migration may refer to migrating the data of the host to another device or migrating the data of another device to the host. For example, if the host is a smart phone, data migration may refer to phone data transfer.

[0056] S202: Interact with the memory through a pre-erasure command, where the pre-erasure parameter includes at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host.

[0057] It should be noted that when the host performs a pre-erasure operation on the memory, pre-erasure parameters need to be used. The pre-erasure parameters may include at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host. Specifically, the maximum pre-erasure capacity supported by the memory may refer to the maximum capacity of pre-erasure that the memory can manage at the same time. Since the memory (such as UFS) usually performs erasure operations in "blocks", the maximum pre-erasure capacity supported by the memory may refer to the maximum number of pre-erasure virtual blocks that the memory can manage at the same time. The current remaining pre-erasure capacity of the memory is the number of pre-erased virtual blocks currently existing in the memory, and the currently required pre-erasure capacity refers to the size of the storage space that the host currently requests to pre-erase. As an implementation, the currently required pre-erasure capacity may be determined based on the current application scenario, that is, based on the current application program, the data volume of the data to be written corresponding to the current application scenario can be determined, and the pre-erasure capacity matching the data volume is determined as the current pre-erasure capacity.

[0058] In the embodiments of the present application, the pre-erasure parameters may include the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host. Then, the way for the host to control the memory to perform the pre-erasure operation can refer to Figure 3 . As Figure 3 described, the host sends a first interaction command to the memory, and this first interaction command instructs the memory to return the maximum pre-erasure capacity supported by the storage device. That is to say, the host queries the maximum pre-erasure capacity supported by the storage device. After receiving the command, the storage device returns the maximum pre-erasure capacity supported by the storage device. Then, the host sets the capacity that the storage device needs to pre-erase. Specifically, the host can determine the currently required pre-erasure capacity. For example, the currently required pre-erasure capacity can be determined based on the current application scenario. Of course, the currently required pre-erasure capacity can also be set based on other reference conditions, which is not limited herein. At the same time, it is also necessary to ensure that the currently required pre-erasure capacity does not exceed the maximum pre-erasure capacity supported by the storage device. Then, the host sets the capacity that the memory needs to erase through a second interaction command, that is, sends the currently required pre-erasure capacity to the memory through the second interaction command. After receiving the command, the storage device determines whether the memory can meet the host's pre-erasure requirements and whether it can meet the pre-erasure capacity. If so, it replies successfully; otherwise, it replies failed. Among them, determining whether the memory can meet the host's pre-erasure requirements may refer to that the memory currently meets the execution conditions of the pre-erasure operation. The specified conditions may include that the memory is working properly. Among them, the memory being working properly means that the memory is not abnormal. Abnormality is also called media abnormality, which means that the memory has been locked and cannot perform "write" operations anymore.

[0059] In addition, the implementation manner for the memory to determine whether it can meet the capacity required for pre-erasure may be that the memory determines whether there are sufficient free blocks and checks whether the pre-erasure capacity currently configured by the host exceeds the maximum pre-erasure capacity supported by the memory. Specifically, the pre-erasure operation on the memory refers to the pre-erasure operation on the free blocks of the memory. It can be understood that when the storage device writes data, the data is written into the free blocks. Here, the free blocks refer to the areas not occupied by valid data, usually a part of the memory, waiting for new data to be written. Before the data is written into the free blocks, a pre-erasure operation needs to be performed on the free blocks. Therefore, after the memory learns the currently required pre-erasure capacity determined by the host, the memory needs to determine whether the current number of free blocks can meet the requirement of the currently required pre-erasure capacity. In addition, although the host ensures that the currently required pre-erasure capacity set does not exceed the maximum pre-erasure capacity supported by the memory when determining the currently required pre-erasure capacity, in some cases, the host may send an abnormal value to the memory. Therefore, the memory needs to determine whether the currently required pre-erasure capacity exceeds the maximum pre-erasure capacity supported by the memory. If at least one of the conditions that the currently required pre-erasure capacity exceeds the maximum pre-erasure capacity supported by the memory and the current number of free blocks cannot meet the requirement of the currently required pre-erasure capacity is satisfied, it is determined that the capacity required for pre-erasure cannot be met.

[0060] Next, the memory can decide when to perform the pre-erasure operation. The memory can perform the pre-erasure operation immediately after receiving the command, or perform the pre-erasure when it is in the idle state. The time point of pre-erasure is determined by the storage device algorithm. Here, the idle state can mean that the memory does not receive a command sent by the host within a specified time period, that is, when the memory determines that it has not received a command sent by the host within the specified time period (for example, 10 ms), it is determined to enter the idle state. It can also be that the host issues a command to enter the low-power state. Specifically, it means that when the host does not generate a new command within a specified time period (for example, 5 ms), the host will actively issue a command to enter the low-power state to let the memory perform operations beneficial to reducing the power consumption of the memory. In this scenario, it can also be considered that the memory is in the idle state.

[0061] In addition, the host can also query the currently pre-erased capacity of the storage device through a third interaction instruction, so that before the host performs a write operation, it can know the remaining pre-erased capacity of the memory, and thus know whether the pre-erased capacity required by the host has been completed by the memory. After the storage device receives the command, it returns how much of the currently pre-erased capacity remains.

[0062] As an implementation manner, the foregoing first interaction command, second interaction command, and third interaction command may be named as pre-erasure commands. That is to say, data interaction can be performed between the host and the memory through the pre-erasure commands. In the case of requesting or sending different data, the content of the pre-erasure commands will be different. It can be understood that the first interaction command, second interaction command, and third interaction command here may refer to different parameters or content transmitted in the pre-erasure commands, and may not be represented as different commands. The pre-erasure command may be an existing command in the memory protocol or a newly defined command, and this is not limited.

[0063] Therefore, in the embodiments of the present application, when the current application scenario of the host belongs to a specified scenario, pre-erasure parameters are determined, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold; through the pre-erasure command, the pre-erasure parameters are interacted with the memory, where the pre-erasure parameters include at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host. Therefore, in the scenario where the host faces a large amount of data to be written, the pre-erasure parameters can be determined and interacted with the memory through the pre-erasure instruction to serve the subsequent pre-erasure operation.

[0064] The different construction methods of the pre-erasure command will be described below.

[0065] Please refer to Figure 4 , this method is applied to the above-mentioned host. The pre-erasure command in this method can be defined based on some fields of a known command in the memory protocol, and parameters corresponding to the pre-erasure function, that is, pre-erasure parameters, can be defined in the reserved field and / or extended field of the known command. Specifically, this method includes: S401 to S403.

[0066] S401: When the current application scenario of the host belongs to a specified scenario, determine pre-erasure parameters, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold.

[0067] S402: Based on the specified field of the first command, construct a pre-erasure command, where the first command includes a command supported by the memory protocol, and the specified field includes at least one of a reserved field and an extended field.

[0068] It can be understood that the first command can be a command supported by the protocol of the memory. In the embodiments of the present application, the memory can be a Universal Flash Storage (UFS), and the protocol of the memory can refer to the UFS protocol. The commands supported by the UFS protocol can include data transfer commands, management commands, status commands, extended commands, error detection and repair commands, self-test commands, device identification commands, and transaction management commands. Among them, the data transfer commands include a read data command (READ), a write data command (WRITE), a READBUFFER command for reading data from the cache, and a WRITE BUFFER command for writing data to the cache. The management commands include: a SYNCHRONIZE CACHE command for ensuring that all data in the cache on the device side is written to non-volatile storage, an ERASE command, a UNMAP command for deleting data in a specified area of the device, and a FORMAT UNIT command, and a START STOP UNIT command for changing the power state of the device. The status commands include: a REPORT LUN command for obtaining the status of a logical unit (LUN), a MODE SENSE command for querying certain characteristics or functions of the device, and a MODE SELECT command for setting certain characteristics or functions of the device. The extended commands include: a UFS QUERY command for querying various information of the device. The error detection and repair commands include: a REQUEST SENSE command for checking the status of the device and a CLEAR CONDITION command for clearing error conditions. The self-test command includes a SENDDIAGNOSTIC command for performing self-test of the device. The device identification commands include an INQUIRY command for obtaining basic information of the device and a READ CAPACITY command for reading capacity information of the device.

[0069] It can be understood that in the embodiments of the present application, it is necessary to construct a pre-erase command using the reserved field and / or the extended field of the command supported by the protocol of the memory. That is to say, by setting the reserved field and / or the extended field, the command can be used as a pre-erase command. Therefore, among all the commands supported by the protocol of the memory, any command with at least one of the reserved field and the extended field can be used as the first command.

[0070] It should be noted that the extension field in the command is to support the flexibility and extensibility of the protocol, allowing new functions or features to be added in future standard versions without affecting the existing command format and functions. The extension field is usually used to support new functions or features, and can add new command parameters or control information in the update of the protocol standard. In other words, by adding extension fields to existing commands, it can be ensured that the introduction of new functions will not affect the compatibility of existing devices. For example, the MODE SELECT command has an extension field, which is used to set the characteristics of the device. The extension field it contains is used to pass additional feature data or identifiers. Through the extension field, the device can support more features. The extension field is usually located in the additional header segment (Extended Header Segment, EHS) of the UFS command structure, and can be flexibly configured as needed.

[0071] The reserved fields in the command, also known as reserved fields, are reserved for future extensions of the protocol. This field has no specific purpose defined in the current protocol version and is usually marked as reserved in the command format. In other words, the existence of reserved fields ensures that the existing command format will not be destroyed when the protocol is extended in the future. When the protocol is updated, the new version can use these reserved fields without redefining the entire command structure. The reserved fields provide space for new functions, parameters, or configurations that may be added in the future. They provide a reserved position for the introduction of new standards, avoiding destructive modifications to existing devices and systems. Still taking the MODE SELECT command as an example, the MODE SELECT command has reserved fields, which are usually not involved in the current command processing. The values ​​of the reserved fields are usually set to zero, and the contents of these fields are ignored when parsing the command.

[0072] It can be seen that both reserved fields and extended fields are currently unused fields. The extended field can be regarded as a "standby" field, which will be defined in the future and used to support new features. The reserved field can be regarded as a "blank" field, which currently has no meaning and is not processed by the device. The value is usually zero. Therefore, the setting or definition of the reserved field or extended field does not affect the existing functions of the command. Therefore, this method of constructing the pre-erase command does not require additional customized commands. It exists in the existing commands in the form of extended fields or reserved fields, and reduces additional command interactions to achieve the purpose of pre-erase and prevent a significant impact on the real-time performance of other commands.

[0073] As an implementation method, assuming that the designated field is an extended field, the implementation method of constructing a pre-erase command may be to configure the first command as a pre-erase command by selecting a value that is not assigned a function in the extended field of the first command and setting it as a target identifier corresponding to the pre-erase function, wherein the data area corresponding to the extended field is used to store the pre-erase parameters. As mentioned above, there are usually some values ​​that are not assigned a function in the extended field, namely the standby field mentioned above. By setting this value, the first command can have a pre-erase function. Specifically, a value that is not assigned a function in the extended field of the first command is set to a target identifier corresponding to the pre-erase function, so that the target identifier can represent that the first command has a pre-erase function. After the memory or host recognizes the first command with the target identifier, it determines that the first command is a pre-erase command, thereby obtaining the pre-erase parameters from the data area corresponding to the extended field.

[0074] Exemplarily, the extended field is an EHS field, and the EHS field can generally include two parts: EHS Type and EHSData. EHS Type specifies the data type or category of the EHS field. EHSData is used to store data related to the device. In an embodiment of the present application, the EHS field of the first command can be used to set whether the type of the first command is a pre-erase command, and the EHSData is used to store pre-erase parameters. Specifically, a value to which a function is not assigned (i.e., an unused value) is selected in EHS Type, and the value to which the function is not assigned is used as the target identifier corresponding to the pre-erase function.

[0075] As an implementation mode, the value of the unassigned function belongs to the specified value range of the EHS field, and the specified value range can be 02H to 7FH, or 80H to FFH. It can be understood that the range of 02H to 7FH includes 02H, 7FH and values ​​between 02H and 7FH, that is, 02H, 03H, 04H, 05H, ..., 7EH, 7FH. Similarly, the range of 80H to FFH includes 80H, FFH and values ​​between 80H and FFH, that is, 80H, 81H, 82H, 83H, ..., FEH, FFH.

[0076] In the embodiment of the present application, illustratively, the value of the unassigned function is 80H of the EHS field, and of course it can also be other unused values ​​within the range, which is not limited here. Then, set the 80H as the identifier of the pre-erase function, that is, the target identifier corresponding to the pre-erase function. After the host and the memory obtain the first command with the target identifier, when it is determined that the target identifier exists in the first command, it can be known that the first command has a pre-erase function, and then the pre-erase parameters are obtained from the EHS Data area.

[0077] That is to say, the value in the extended field of the first command that is not assigned a function can be set to the target identifier corresponding to the pre-erasure function, and the data area of this extended field is defined to store pre-erasure parameters. After this setting, the first command can be used as a pre-erasure command by the host or the memory. In the embodiments of the present application, the first command can be a command including an EHS field among the commands supported by the UFS protocol. For example, it can be a Write or Read command. Of course, it can also be other commands, and no limitation is made thereto.

[0078] As Figure 5 shown, Figure 5 shows the architecture of the pre-erasure command obtained by setting the EHS field. Specifically, Figure 5 the content highlighted in bold in [ ] can be regarded as the setting of the EHS field. It can be seen that in EHSType, an unused value 80H is selected and described as the identifier of the pre-erasure function (Pre Erase), that is, the aforementioned target identifier. And the EHS Data area defines three parameters, such as Figure 5 the three parameters highlighted in bold in [ ], which are PreEraseSetCap, PreEraseCurCap, and PreEraseMaxCapt respectively. These three parameters are used to characterize the pre-erasure parameters used in the embodiments of the present application, and the meanings of these three parameters are shown in Table 1.

[0079] Table 1

[0080]

[0081] That is to say, PreEraseSetCap is the pre-erasure capacity currently configured by the host, PreEraseCurCap is the remaining pre-erasure capacity of the memory currently, and PreEraseMaxCap is the maximum pre-erasure capacity supported by the memory. Among them, the PreEraseSetCap can be the total amount of pre-erasure that the host expects the memory to perform. Of course, it can also be the capacity that the host expects the memory to continue erasing, that is, as an increment.

[0082] As an implementation manner, the PreEraseSetCap can be the total amount of pre-erasure that the host expects the memory to perform. Then, the specific example in Table 2 can be used to illustrate the PreEraseSetCap. Assume that PreEraseMaxCap is 10, which is used to represent that the maximum pre-erasure capacity supported by the memory is 10 GB.

[0083] Table 2

[0084]

[0085]

[0086] It should be noted that the above X indicates that PreEraseCurCap is an arbitrary value, but always satisfies “less than or equal to PreEraseMaxCap”.

[0087] As another implementation, the PreEraseSetCap can also be an increment, that is, a pre-erase capacity further increased on the basis of the existing pre-erase capacity. Please refer to Table 3, which illustrates the PreEraseSetCap through the example of Table 3. Similarly, assuming that PreEraseMaxCap is 10, it is used to indicate that the maximum pre-erase capacity supported by the memory is 10GB.

[0088] Table 3

[0089]

[0090]

[0091] S403: exchanging pre-erase parameters with the memory through a pre-erase command.

[0092] It should be noted that the contents not described in detail in the above steps can be referred to the aforementioned embodiments and will not be described again here.

[0093] Therefore, by setting the corresponding pre-erase parameters in the data area corresponding to the extended field, the pre-erase command constructed based on the extended field or the reserved field of the first command can be used to transmit the pre-erase parameters. And the pre-erase command constructed based on the command supported by the memory protocol will not cause the function loss of the command, and the purpose of pre-erase can be achieved by reducing additional command interactions, so as to prevent a significant impact on the real-time performance of other commands.

[0094] See also Figure 6 The method is applied to the above-mentioned host, and the pre-erase command in the method can be set based on the transformation of a known command of the memory protocol, that is, using the known command, it can switch between the original function and the pre-erase function to complete the transfer of the pre-erase parameters. Specifically, the method includes: S601 to S604.

[0095] S601: Determine a pre-erase parameter when the current application scenario of the host belongs to a specified scenario, wherein the specified scenario is used to indicate that the amount of data corresponding to the data to be written is greater than a specified threshold.

[0096] S602: Setting a mode field in a second command, where the second command belongs to commands supported by a protocol of the memory.

[0097] and Figure 4 The method of the corresponding embodiment is different in that, in the embodiment of the present application, the method of constructing the pre-erase command is to transform the second command, i.e., the command supported by the protocol of the memory, to give it a new function, which belongs to the construction of a command other than the command supported by the protocol of the memory. However, the architecture of the command can be the architecture of the command supported by the protocol of the memory. That is to say, on the basis of a known command (i.e., the command supported by the protocol of the memory), by adding a mode field, it has different modes, i.e., the pre-erase mode and the original mode, and the original mode is the initial function of the second command.

[0098] It can be understood that the second command also belongs to the commands supported by the protocol of the memory. The implementation of the commands supported by the protocol of the memory can refer to the above content and will not be repeated here.

[0099] S603: Setting the mode field of the second command to a specified value, and configuring the second command as a pre-erase command, wherein the specified value is used to indicate that the current function of the second command is a pre-erase function.

[0100] As an implementation, the value set for the mode field can be used to set whether the second command is used as a pre-erase command or as the original second command. That is, assuming that the second command has a pre-erase function and other functions, the pre-erase function includes passing pre-erase parameters, and the other functions may include an initial function, which may be the default function of the second command. For example, the second command is a Write Buffer command, and its initial function is used to write data to the cache. Therefore, by setting the value of the mode field, the second command can be switched between the pre-erase function and the initial function.

[0101] In an embodiment of the present application, it can be set that when the mode field is set to a specified value, the second command is used as a pre-erase command, that is, the specified value can characterize that the current function of the second command is a pre-erase function, and when the mode field is not a specified value, the second command executes the initial function or other functions.

[0102] As an implementation, the implementation of setting the mode field within the second command can be to set the first bit to the second bit of a specified byte in the second command, that is, select a certain number of bits between a byte in the second command as the mode field. Exemplarily, assuming that the second command is a Write Buffer command or a Read Buffer command, a certain number of bit positions can be selected in this command and set as the mode field. For example, if the specified byte is byte1, the first bit is bit0, and the second bit is bit4, that is, select bit0 to bit4 of byte1 in the Write Buffer command or the Read Buffer command and set it as the mode field.

[0103] It can be understood that assuming that the memory is a UFS memory, in the UFS protocol, one byte represents one byte of the command, and different bytes form the command in a specific order. Each byte is responsible for representing different parts or parameters of the command, and each byte plays a specific role in the command structure. For example, in the Write Buffer command, byte1 is used to control or specify some operation parameters. As Figure 7 shown, between bit0 and bit4 of byte1 of the command is defined as the mode field (Mode). As Figure 8 shown, it shows the value of Mode and its represented meaning. It can be seen that the specified value can be 0x1D, that is Figure 8 the content highlighted in bold in

[0104] S604: Through the pre-erase command, interact with the memory for pre-erase parameters.

[0105] It should be noted that the content not described in detail in the above steps can refer to the foregoing embodiments and will not be elaborated herein.

[0106] Therefore, through the reconstruction of the known command, it can be switched between the pre-erase function and other functions by switching the mode, so that the host and the memory can interact with each other for pre-erase parameters through this command.

[0107] Please refer to Figure 9 , this method is applied to the above-mentioned host. This method can be based on the known operation codes of the memory protocol, and set a new operation code as the pre-erase command corresponding to the pre-erase function. Specifically, this method includes: S901 to S903.

[0108] S901: When the current application scenario of the host belongs to a specified scenario, determine pre-erasure parameters, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold.

[0109] S902: Obtain a pre-erasure command by newly defining an operation code in the interface protocol command set of the memory.

[0110] It can be understood that the operation code (Opcode) is a part of the computer instruction set, representing the encoding of a specific operation. During the execution of a computer program, the operation code specifies the type of operation that the CPU needs to execute. It is a part of the instruction and is usually used to identify the function of the instruction. Generally, the operation code belongs to a part of the command set of the interface protocol. In any communication protocol or bus protocol, the operation code is an instruction used to specify a specific operation to be executed.

[0111] Since the host and the memory interact through the interface protocol command set to implement operations such as data reading, writing, and erasing, therefore, by defining a new operation code in this interface protocol command set, this operation code, as the exclusive operation code for the pre-erasure function and the pre-erasure command, can implement the interactive operation of the pre-erasure parameters between the host and the memory.

[0112] As an implementation manner, the memory is a UFS memory, and the interface protocol command set is the UFS SCSI Command Set. Specifically, the SCSI Command Set is a set of standard commands defined in the Small Computer System Interface (SCSI) protocol. These commands are used to communicate with storage devices (such as hard disks, SSDs, UFS storage devices) and perform various operations (such as reading, writing, formatting, erasing, etc.). The UFS SCSI Command Set is the SCSI command set used by UFS storage devices.

[0113] In the embodiment of the present application, a new Opcode can be defined in the UFS SCSI Command Set as the pre-erasure command. As Figure 10 shown, the newly defined operation code is PRE_ERASE, and its corresponding Opcode value and Command support are not shown in the figure, and its specific content is not limited herein, where the ellipsis represents other operation codes not shown.

[0114] As Figure 11As shown, the byte numbers of three pre-erasure variables are defined within the data area. PreEraseSetCap corresponds to the 0th byte, PreEraseCurCap corresponds to the 1st byte, and PreEraseMaxCap corresponds to the 2nd byte. Assuming that the opcode consists of an opcode, a parameter type, and a capacity value, the pre-erasure command formed by this opcode can be [opcode name parameter type, capacity]. For example, PRE_ERASE 1, 20; which means that the parameter for interaction is the pre-erasure capacity currently configured by the host, and the specific capacity is 20 GB.

[0115] S903: Interact with the memory to exchange pre-erasure parameters through a pre-erasure command.

[0116] It should be noted that the content not described in detail in the above steps can be referred to the foregoing embodiments and will not be elaborated here.

[0117] Therefore, by defining a new Opcode in the UFS SCSI Command Set, when the host or the storage device wants to transfer a value, the variable at the corresponding position provides the value. This enables the host and the memory to interact with pre-erasure parameters based on this opcode.

[0118] Please refer to Figure 12 , this method is applied to the above-mentioned host. This method can define new attributes based on known requests of the memory protocol. Therefore, requests containing these attributes can be used as pre-erasure commands. Specifically, this method includes: S1201 to S1203.

[0119] S1201: When the current application scenario of the host belongs to a specified scenario, determine the pre-erasure parameters, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold.

[0120] S1202: Obtain a pre-erasure command by defining target attribute parameters in the parameter set of a specified request.

[0121] Taking the memory as UFS as an example, in the UFS protocol, the parameter set (Attributes) is used to transfer detailed configuration parameters of a specific command or request. Therefore, when sending a request, the request often carries a parameter set. So, by defining target attribute parameters in the parameter set, the host and the memory can transfer pre-erasure parameters through this target attribute parameter. That is to say, the target attribute parameter is used to transfer the pre-erasure parameter. Therefore, the specified request carrying this target attribute parameter can be regarded as a pre-erasure command. That is to say, a pre-erasure command can be issued through a specified request.

[0122] In the embodiments of the present application, the specified request is a query request or a task management request. Through this request, the target attribute parameter can be read from or written to, so as to realize the interaction of the pre-erase parameter. That is to say, the target attribute parameter is added to the parameter set corresponding to the specified request. Through the read parameter request or write parameter request under the specified request, the target attribute parameter is written to the memory or read from the memory. Therefore, by setting the parameter identifiers corresponding to different pre-erase parameters, the writing or reading of different pre-erase parameters can be realized.

[0123] Exemplarily, assume that the memory is a UFS memory. The specified request can be a Query Request or a Task Management Request. In the UFS protocol, Query Request is used to query the device status, characteristics or information from the device, and Task Management Request is used to manage, control or terminate the tasks ongoing on the device. Whether it is a query request or a task management request, there is a corresponding parameter set Attributes. Then, the target attribute parameter is defined in this parameter set. In the embodiments of the present application, the target attribute parameter can be three, namely the aforementioned PreEraseSetCap, PreEraseCurCap and PreEraseMaxCap. Thus, by reading the corresponding parameters through the specified request, the corresponding content can be obtained. For example, query PreEraseMaxCap in the memory to obtain the maximum pre-erase capacity supported by the memory.

[0124] Such as Figure 13As shown, it shows the identifier corresponding to the target attribute parameter. Therefore, when the host or storage device wants to transfer values, the Read Attributes and Write Attributes methods in the Query request are used to complete the parameter transfer. It should be noted that the Query request can be understood as the request type defined by the UFS protocol. There are also various more detailed requests under this request. Read Attributes and Write Attributes are the specific implementations of the Query request. Both ReadAttributes and Write Attributes are implemented through the Query request and are used to read and modify the attributes of the device. Therefore, after defining the above three attribute parameters in Attributes, the reading and writing of the attribute parameters can be completed through the Read Attributes and Write Attributes methods, that is, the interaction operation of the pre-erasure parameters is realized. Therefore, the Read Attributes and Write Attributes requests, and the corresponding parameter identifier is the identifier corresponding to the pre-erasure parameter, are regarded as the pre-erasure command.

[0125] S1203: Interact with the memory to transfer pre-erasure parameters through the pre-erasure command.

[0126] It should be noted that the content not described in detail in the above steps can be referred to the foregoing embodiments and will not be elaborated herein.

[0127] Therefore, the pre-erasure command is issued through other requests such as Query Request or Task Management Request. For example, use the method of accessing Attributes in the Query command to define three new attributes. When the host or storage device wants to transfer values, the Read Attributes and Write Attributes methods in the Query hit are used to complete the parameter transfer.

[0128] Please refer to Figure 14 , this method is applied to the above-mentioned host. This method can determine whether the memory supports the pre-erasure function before determining the specific pre-erasure parameters. Specifically, since the purpose of pre-erasure is to further improve the writing performance of the storage device in the scenario of high-pressure writing, the pre-erasure function will be enabled when the host enables WriteBooster, and this function is only applicable to the SLC blocks of WriteBooster. That is to say, the object of pre-erasure is the SLC block. Therefore, if the WriteBooster of the storage device is disabled, the pre-erasure function should also be disabled. Specifically, this method includes: S1401 to S1402.

[0129] S1401: If the memory supports the pre-erasure function, determine the pre-erasure parameters when the current application scenario of the host belongs to a specified scenario.

[0130] As described above, when WriteBooster is disabled, the pre-erasure function will also be disabled. Therefore, for the memory, there is a case where the pre-erasure function is disabled. So, to ensure the smooth progress of the pre-erasure operation, it is necessary to first determine whether the memory supports the pre-erasure function.

[0131] As an implementation manner, the ways for the host to determine whether the memory supports the pre-erasure function can at least include the following two ways:

[0132] The host and the memory can agree to select a certain bit within a certain field in the UFS protocol to represent whether the pre-erasure function of the memory is disabled, that is, whether the memory supports the pre-erasure function.

[0133] The first way: Obtain the value of the first specified bit in the extended feature support field of the device descriptor in the protocol of the memory. The first specified bit is used to mark the pre-erasure function. If the value of the first specified bit is the first specified value, it is determined that the memory supports the pre-erasure function; otherwise, it is determined that the memory does not support the pre-erasure function.

[0134] Exemplarily, as Figure 15 shown, the memory is a universal flash memory, the device descriptor is DeviceDescriptor, the extended feature support field is dExtendedUFSFeaturesSupport, and the first specified bit can be the reserved bit corresponding to this extended feature support field. It should be noted that the reserved bit refers to the bit that is not currently assigned a function, and can also be understood as a value that is not used. It is usually the bit reserved in the UFS protocol for future expansion or compatibility. As an implementation manner, as Figure 15 shown, the reserved bit (Reserved) corresponding to this extended feature support field can be bit20 to bit31. That is to say, the first specified bit is within the range of bit20 to bit31. It can be understood that the range of bit20 to bit31 includes bit20, bit31, and the bits between bit20 and bit31.

[0135] In the embodiments of the present application, as Figure 16As shown, the first designated bit is Bit

[22] . Of course, it can also be other unused bits within this range, which is not limited here. In the UFS protocol, a Device Descriptor is a structure that contains basic device information. It describes various characteristics and capabilities of the UFS device, helping the host understand important information such as the device's capabilities, version, supported functions, etc. dExtendedUFSFeaturesSupport is a field in the Device Descriptor, indicating the extended functions supported by the UFS device. Therefore, selecting a bit in the field used to characterize the extended functions supported by the memory to characterize whether the memory supports the pre-erase function can be used as an extension of the content of this extended feature support field.

[0136] For example Figure 15 As shown in, Bit

[22] is used as the first designated bit, that is, Bit

[22] is used as a flag indicating whether the storage device supports the pre-erase function. The first designated value is set to 1. If Bit

[22] is 1, it means the storage device supports the pre-erase function. If Bit

[22] is not 1, for example, 0, it means the storage device does not support the pre-erase function.

[0137] In the second method, obtain the value of the second designated bit in the write acceleration support field of the device descriptor in the protocol of the memory. The second designated bit is used to mark the pre-erase function. If the value of the second designated bit is the second designated value, it is determined that the memory supports the pre-erase function; otherwise, it is determined that the memory does not support the pre-erase function.

[0138] Exemplarily, as Figure 17 shown, the memory is a universal flash memory, the device descriptor is DeviceDescriptor, and the write acceleration support field is wExtendedWriteBoosterSupport. The second designated bit can be an unused value in this field, that is, the second designated bit is the reserved bit corresponding to the write acceleration support field.

[0139] As an implementation manner, the reserved bits corresponding to the write acceleration support field may be bit3 to bit15. That is to say, the second specified bit belongs to the range of bit3 to bit15. It can be understood that the range of bit3 to bit15 includes bit3, bit15, and the bits between bit3 and bit15. In the embodiment of the present application, the second specified bit is Bit[3]. Of course, it can also be other unused bits within this range, which is not limited herein. In the UFS protocol, wExtendedWriteBoosterSupport is a field in the Device Descriptor, which is used to indicate whether the device supports the Extended Write Booster function. That is to say, it is used to inform the host device whether it supports the extended write accelerator function.

[0140] It should be noted that any value within the value range provided in the present application can be used without being assigned a function. Taking the second specified bit as an example, in the wExtendedWriteBoosterSupport field, bit0 to bit2 have been used, and bit3 to bit15 are all reserved bits. Therefore, for the newly added function of marking pre-erasure, the first of the reserved bits (that is, bit3) is preferentially used. If bit3 is also used, then bit4, bit5, and subsequent bits are taken in turn until bit15. Therefore, within this range, based on the usage of each bit, the second specified bit can be selected as the marker bit for the pre-erasure function. For example, the first unused reserved bit can be selected as the second specified bit, which is not limited herein.

[0141] It can be understood that for a memory, the free blocks generally have two modes: SLC and TLC, and even QLC and PLC. Here, SLC and TLC are taken as examples. When 1 free block is used as SLC, the capacity is only one-third of that of TLC. Therefore, when the free block is set as an SLC block, the write speed is fast but the capacity is small. When the free block is set as a TLC block, the write speed is relatively slow but the capacity is 3 times that of the SLC block. Therefore, writebooster means that the memory has a certain number of SLC free blocks to handle the burst writes of the host, so that the write performance is relatively good. Then, when idle, the data is moved from SLC to TLC, so that the user cannot perceive the slowness. The object of pre-erasure is the SLC block, so pre-erasure can be regarded as an enhanced usage of writebooster. Therefore, by selecting a bit in the wExtendedWriteBoosterSupport field to indicate whether the memory supports the pre-erasure function, the determination of the pre-erasure function can be linked with the WriteBooster Feature for use.

[0142] From the above description, it can be seen that the pre-erase function can be regarded as an enhanced function of writebooster. Therefore, the pre-erase function is usually associated with the Write Booster function. Therefore, by using Bit[3] of the wExtendedWriteBoosterSupport field as the identification bit for supporting the pre-erase function, the host can query the wExtendedWriteBoosterSupport field to determine whether the device supports both the Write Booster and pre-erase functions.

[0143] For example Figure 17 As shown in , Bit[3] is used as the second designated bit, that is, Bit[3] is used as a flag to indicate whether the storage device supports the pre-erase function, and the second designated value is set to 1. If Bit[3] is 1, it indicates that the storage device supports the pre-erase function. If Bit[3] is not 1, for example, it is 0, it indicates that the storage device does not support the pre-erase function. Therefore, an unused bit is selected in wExtendedWriteBoosterSupport of DeviceDescriptor, such as Bit[3] as the determination bit of whether the pre-erase function is supported. The embodiment of the present application can be used in conjunction with the WriteBooster Feature, and support can be marked in the form of a sub-function.

[0144] S1402: exchanging pre-erase parameters with the memory through a pre-erase command.

[0145] It should be noted that the contents not described in detail in the above steps can be referred to the aforementioned embodiments and will not be described again here.

[0146] Therefore, by selecting a bit in the dExtendedUFSFeaturesSupport field or the wExtendedWriteBoosterSupport field of the Device Descriptor as a discrimination bit for supporting the pre-erase function, and determining whether the memory supports the pre-erase function by agreeing on the value of the discrimination bit, it is possible to determine whether the memory supports the pre-erase function based on the UFS protocol.

[0147] See also Figure 18 , which shows a structural block diagram of a memory management device 1700 provided in an embodiment of the present application. The device may include: a determination unit and an interaction unit.

[0148] A determination unit 1701, configured to determine pre-erasure parameters when the current application scenario of the host belongs to a specified scenario, where the specified scenario is used to represent that the data volume corresponding to the data to be written is greater than a specified threshold.

[0149] An interaction unit 1702, configured to interact with the memory through a pre-erasure command, where the pre-erasure parameters include at least one of the maximum pre-erasure capacity supported by the memory, the current remaining pre-erasure capacity of the memory, and the pre-erasure capacity currently configured by the host.

[0150] Furthermore, the memory management device further includes a construction unit, configured to construct a pre-erasure command based on a specified field of the first command, where the first command includes a command supported by the protocol of the memory, and the specified field includes at least one of a reserved field and an extended field.

[0151] Furthermore, the construction unit is further configured to configure the first command as a pre-erasure command by selecting a value that has not been assigned a function in the extended field of the first command and setting it as a target identifier corresponding to the pre-erasure function, where the data area corresponding to the extended field is used to store the pre-erasure parameters.

[0152] Furthermore, the memory is a general flash memory, the extended field is an EHS field, and the value that has not been assigned a function is 80H of the EHS field.

[0153] Furthermore, the construction unit is further configured to set a mode field in a second command, where the second command belongs to a command supported by the protocol of the memory; set the mode field of the second command to a specified value, and configure the second command as a pre-erasure command, where the specified value is used to represent that the current function of the second command is a pre-erasure function.

[0154] Furthermore, the second command is at least one of a read command and a write command supported by the protocol of the memory, the read command is a Write Buffer command, and the write command is a Read Buffer command.

[0155] Furthermore, the construction unit is further configured to set the first bit to the second bit of a specified byte in the second command as the mode field.

[0156] Furthermore, the specified byte is byte1, the first bit is bit0, and the second bit is bit4.

[0157] Furthermore, the construction unit is further configured to obtain a pre-erasure command by newly defining an operation code in the interface protocol command set of the memory.

[0158] Further, the building unit is further configured to obtain a pre-erasure command by defining target attribute parameters in a parameter set of a specified request, where the target attribute parameters are used to transfer the pre-erasure parameters.

[0159] Further, the determining unit 1701 is further configured to determine pre-erasure parameters if the memory supports the pre-erasure function and the current application scenario of the host belongs to a specified scenario.

[0160] Further, the determining unit 1701 is further configured to obtain a value of a first specified bit in an extended feature support field of a device descriptor in the protocol of the memory; if the value of the first specified bit is a first specified value, it is determined that the memory supports the pre-erasure function, otherwise, it is determined that the memory does not support the pre-erasure function.

[0161] Further, the memory is a universal flash memory, the device descriptor is DeviceDescriptor, the extended feature support field is dExtendedUFSFeaturesSupport, and the first specified bit is Bit

[22] .

[0162] Further, the determining unit 1701 is further configured to obtain a value of a second specified bit in a write acceleration support field of a device descriptor in the protocol of the memory; if the value of the second specified bit is a second specified value, it is determined that the memory supports the pre-erasure function, otherwise, it is determined that the memory does not support the pre-erasure function.

[0163] Further, the memory is a universal flash memory, the device descriptor is DeviceDescriptor, the write acceleration support field is wExtendedWriteBoosterSupport, and the second specified bit is a reserved bit.

[0164] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0165] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical, or other forms of coupling.

[0166] In addition, in each embodiment of the present application, each functional module may be integrated in a processing module, or each module may exist physically alone, or two or more modules may be integrated in one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0167] Please refer to Figure 19, which shows a structural block diagram of a computer-readable medium provided by an embodiment of the present application. Program code is stored in the computer-readable medium 1800, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0168] The computer-readable medium 1800 can be an electronic memory such as a flash memory, EEPROM (electrically erasable programmable read-only memory), EPROM, hard disk, or ROM. Optionally, the computer-readable medium 1800 includes a non-transitory computer-readable storage medium. The computer-readable medium 1800 has a storage space for the program code 1810 that executes any method step in the above method. These program codes can be read out from or written into one or more computer program products. The program code 1810 can be compressed in an appropriate form, for example.

[0169] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A memory management method, characterized in that: A host applied to a storage system, the storage system further comprising the storage, the host being connected to the storage, the method comprising: In a case where the current application scenario of the host belongs to a specified scenario, determining a pre-erase parameter, wherein the specified scenario is used to indicate that the amount of data corresponding to the data to be written is greater than a specified threshold; Pre-erase parameters are exchanged with the memory through a pre-erase command, wherein the pre-erase parameters include at least one of a maximum pre-erase capacity supported by the memory, a currently remaining pre-erase capacity of the memory, and a pre-erase capacity currently configured by the host.

2. The method according to claim 1, characterized in that: Before sending the current pre-erase capacity to the memory through the pre-erase command, the method further includes: A pre-erase command is constructed based on a designated field of a first command, wherein the first command includes a command supported by a protocol of the memory, and the designated field includes at least one of a reserved field and an extended field.

3. The method according to claim 2, characterized in that The designated field is an extended field in the first command, and the pre-erase command is constructed based on the designated field of the first command, including: The first command is configured as a pre-erase command by selecting a value to which no function is assigned in the extension field of the first command and setting it as a target identifier corresponding to the pre-erase function, wherein the data area corresponding to the extension field is used to store the pre-erase parameters.

4. The method according to claim 3, characterized in that The memory is a universal flash memory, the extended field is an EHS field, and the value to which no function is assigned belongs to a specified value range of the EHS field.

5. The method according to claim 4, characterized in that The specified value range is 02H to 7FH, or 80H to FFH.

6. The method according to claim 5, characterized in that The value of the unassigned function is 80H of the EHS field.

7. The method according to claim 1, characterized in that Before sending the current pre-erase capacity to the memory through the pre-erase command, the method further includes: setting a mode field in a second command, the second command being a command supported by a protocol of the memory; The mode field of the second command is set to a specified value to configure the second command as a pre-erase command, and the specified value is used to indicate that the current function of the second command is a pre-erase function.

8. The method according to claim 7, characterized in that The second command is at least one of a read command and a write command supported by a protocol of the memory, the read command is a Write Buffer command, and the write command is a Read Buffer command.

9. The method according to claim 7, characterized in that: Set the mode field in the second command, including: Set the first bit to the second bit of the specified byte in the second command as a mode field.

10. The method according to claim 9, characterized in that The designated byte is byte1, the first bit is bit0, and the second bit is bit4.

11. The method according to claim 1, characterized in that: Before sending the current pre-erase capacity to the memory through the pre-erase command, the method further includes: The pre-erase command is obtained by newly defining an operation code in the interface protocol command set of the memory.

12. The method according to claim 1, characterized in that Before sending the current pre-erase capacity to the memory through the pre-erase command, the method further includes: The pre-erase command is obtained by defining a target attribute parameter in a parameter set of a specified request, wherein the target attribute parameter is used to transfer the pre-erase parameter.

13. The method according to claim 12, characterized in that The designated request is a query request or a task management request.

14. The method according to any one of claims 1 to 12, characterized in that: The step of determining the pre-erasing parameter when it is determined that the current application scenario of the host belongs to the specified scenario includes: If the memory supports a pre-erase function, and the current application scenario of the host belongs to a specified scenario, a pre-erase parameter is determined.

15. The method according to claim 14, characterized in that If the memory supports the pre-erase function, and when the current application scenario of the host belongs to the specified scenario, before determining the pre-erase parameter, the method further includes: Obtaining a value of a first designated bit in an extended feature support field of a device descriptor in a protocol of the memory, wherein the first designated bit is used to mark a pre-erase function; If the value of the first designated bit is the first designated value, it is determined that the memory supports the pre-erase function; otherwise, it is determined that the memory does not support the pre-erase function.

16. The method according to claim 15, characterized in that The memory is a universal flash memory, the device descriptor is Device Descriptor, the extended feature support field is dExtendedUFSFeaturesSupport, and the first designated bit is a reserved bit corresponding to the extended feature support field.

17. The method according to claim 16, characterized in that The first designated bit is within the range of bit20 to bit31.

18. The method according to claim 17, characterized in that The first designated bit is Bit[22].

19. The method according to claim 14, characterized in that If the memory supports the pre-erase function, and when the current application scenario of the host belongs to the specified scenario, before determining the pre-erase parameter, the method further includes: Obtaining a value of a second designated bit of a write acceleration support field of a device descriptor in a protocol of the memory, wherein the second designated bit is used to mark a pre-erase function; If the value of the second designated bit is the second designated value, it is determined that the memory supports the pre-erase function; otherwise, it is determined that the memory does not support the pre-erase function.

20. The method according to claim 19, characterized in that The memory is a general flash memory, the device descriptor is Device Descriptor, the write acceleration support field is wExtendedWriteBoosterSupport, and the second designated bit is a reserved bit corresponding to the write acceleration support field.

21. The method according to claim 20, characterized in that The second designated bit is within the range of bit3 to bit15.

22. The method according to claim 21, characterized in that The second designated bit is Bit[3].

23. A memory management device, characterized in that: A host applied to a storage system, the storage system further comprising the memory, the host being connected to the memory, the device comprising: a determining unit, configured to determine a pre-erase parameter when a current application scenario of the host belongs to a specified scenario, wherein the specified scenario is used to indicate that a data amount corresponding to the data to be written is greater than a specified threshold; An interaction unit is used to exchange pre-erase parameters with the memory through a pre-erase command, wherein the pre-erase parameters include at least one of a maximum pre-erase capacity supported by the memory, a currently remaining pre-erase capacity of the memory, and a pre-erase capacity currently configured by the host.

24. A storage system, characterized in that: include: Host; Memory; The host is connected to the memory, and the host is used to execute the method according to any one of claims 1-22.

25. A computer readable medium, characterized in that The computer-readable medium stores a program code executable by a processor, and when the program code is executed by the processor, the processor executes the method according to any one of claims 1 to 22.

Images