An emulator and emulation method for a storage device

Abstract

The application provides an emulator and an emulation method for a storage device, the emulator comprising a memory and a processor; the memory is used for storing a program or instructions for implementing an emulation test and a set of metadata records; each metadata record in the set of metadata records corresponds to each data unit with a preset granularity in the storage device to be emulated; each metadata record comprises a unit identification field, a write bitmap field and a modification times field; the processor is configured to update a corresponding metadata record in response to a write command and to check the above three fields in a read metadata record in response to a read command. The application replaces the storage of real data content with metadata records, greatly reduces the consumption of hardware resources, and enables the emulation of a large-capacity storage device to run on an ordinary development device; meanwhile, the accuracy of the emulation check is ensured without relying on the comparison of real data content through the cooperative check of the three fields.

Description

Technical Field

[0001] This application relates to the field of storage device simulation technology, and specifically to a simulator and simulation method for storage devices. Background Technology

[0002] In the firmware development process of storage devices (such as eMMC, SSD, UFS, etc.), simulation environments are an important means to accelerate firmware optimization and verification. By simulating the hardware behavior of real storage devices through software simulators, developers can debug and test various functions of the firmware without relying on physical hardware. Simulation environments support operations such as starting and stopping at any time, setting breakpoints, single-step debugging, and error injection, which can significantly shorten the firmware development and debugging cycles. At the same time, simulation environments can also be integrated into continuous integration systems to achieve automated regression testing, automatically running a large number of test cases after each code commit to discover firmware defects as early as possible.

[0003] In storage device firmware simulation, the simulation of flash memory is a crucial step. Flash memory simulation requires simulating the firmware's complex management logic, including read / write operations, address mapping, garbage collection, wear leveling, and power-off recovery. Current technologies typically employ full-scale simulation to achieve this: the emulator allocates a storage space in its random access memory (RAM) with the exact same capacity as the flash memory to be simulated, storing all data in the simulated flash memory one-to-one. For example, to simulate a 4GB flash memory chip, the emulator needs to allocate 4GB of RAM to store all user data written to that flash memory exactly as is. When the firmware writes data to a specific address in the simulated flash memory, the emulator stores this data unchanged into the corresponding memory location; when the firmware reads data from a specific address, the emulator reads the data from the corresponding memory location and compares it byte-by-byte with the expected data to verify the correctness of the firmware's read / write logic.

[0004] However, with the rapid increase in flash memory capacity, from 4GB and 16GB to 64GB, 128GB, 256GB, and even larger, the hardware resource requirements for full-scale simulation have also expanded dramatically. Simulating a 256GB flash memory requires at least 256GB of random access memory to store user data. Adding the operating system and other management overhead, a high-performance server with 384GB or even more memory is often needed. This results in persistently high hardware costs for development environments. Furthermore, due to the extremely large amount of data that the simulation environment needs to maintain, operations such as startup loading, snapshot saving, and state restoration become very time-consuming. A complete test process can take tens of minutes or even longer, severely impacting development and debugging efficiency. Summary of the Invention

[0005] This application provides a simulator and simulation method for storage devices, aiming to solve the problems of excessive hardware resource consumption and high development costs caused by the existing full-data simulation method due to the complete storage of real data.

[0006] In a first aspect, embodiments of this application provide an emulator for a storage device, comprising:

[0007] Memory is used to store programs or instructions for implementing simulation tests, as well as metadata record sets;

[0008] Each metadata record in the metadata record set corresponds to a data unit with a preset granularity in the storage device to be simulated. Each metadata record includes a unit identifier field, a write bitmap field, and a modification count field. The unit identifier field records the identifier information of the corresponding data unit, which is determined based on the target logical address to which the data unit is written. The write bitmap field records the write status of each smallest data unit within the corresponding data unit. The modification count field records the total number of times the corresponding data unit has been modified.

[0009] The processor is configured to, in response to an input write command, determine the corresponding data unit based on the target logical address and version information in the write command, and update the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit; and, in response to an input read command, determine the corresponding data unit based on the target logical address and expected version information in the read command, read the metadata record corresponding to the data unit, and verify the read unit identifier field, write bitmap field, and modification count field.

[0010] In some embodiments, the number of bits in the unit identifier field is configured to be a number of bits determined based on the total number of data units, and the stored identifier information is a value corresponding to the integer quotient obtained by the target logical address of the data unit being written and the number of the smallest data units; the number of bits in the write bitmap field is configured to be equal to the number of the smallest data units contained in each data unit; and the number of bits in the modification count field is configured to be a number of bits determined based on the maximum number of times the data unit can be modified.

[0011] In some embodiments, when the processor updates the metadata record, it is configured to: write identification information determined based on the target logical address into the unit identifier field, set the corresponding bit of the smallest data unit corresponding to the target logical address in the write bitmap field, and write the version information into the modification count field.

[0012] In some embodiments, when the processor verifies the read unit identifier field, write bitmap field, and modification count field, it is configured to: verify whether the identifier information in the unit identifier field is consistent with the identifier information determined based on the target logical address; verify whether the bit corresponding to the smallest data unit in the write bitmap field indicates that it has been written; and verify whether the value of the modification count field is equal to the expected version information; if any verification fails, the read operation is determined to be incorrect.

[0013] In some embodiments, the memory is also used to store management data of the storage device to be simulated; the processor is also configured to perform simulation tests on the management data in full storage mode.

[0014] In some embodiments, the storage device to be emulated includes any one of NAND Flash, SSD, eMMC, or UFS devices.

[0015] Secondly, embodiments of this application provide a method for simulating a storage device, comprising:

[0016] Obtain a metadata record set; each metadata record in the metadata record set corresponds to a data unit with a preset granularity in the storage device to be simulated; each metadata record includes a unit identifier field, a write bitmap field, and a modification count field; the unit identifier field is used to record the identifier information of the corresponding data unit, and the identifier information is determined based on the target logical address to which the data unit is written; the write bitmap field is used to record the write status of each smallest data unit within the corresponding data unit; the modification count field is used to record the total number of times the corresponding data unit has been modified;

[0017] In response to a write command, based on the target logical address and version information in the write command, the data unit corresponding to the target logical address is determined, and the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit are updated;

[0018] In response to a read command, based on the target logical address and expected version information in the read command, the data unit corresponding to the target logical address is determined, the metadata record corresponding to the data unit is read, and the read unit identifier field, write bitmap field, and modification count field are verified.

[0019] In some embodiments, updating the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit includes: writing the identifier information determined based on the target logical address into the unit identifier field; setting the corresponding bit in the write bitmap field for the smallest data unit corresponding to the target logical address; and writing the version information into the modification count field.

[0020] In some embodiments, the verification of the read unit identifier field, write bitmap field, and modification count field includes: verifying whether the identifier information in the unit identifier field is consistent with the identifier information determined based on the target logical address; verifying whether the bit corresponding to the smallest data unit in the write bitmap field indicates that it has been written; verifying whether the value of the modification count field is equal to the expected version information; if any verification fails, the read operation is determined to be incorrect.

[0021] In some embodiments, the simulation method for the storage device further includes: acquiring management data of the storage device to be simulated; writing the management data into the management data storage area of ​​the simulator according to the original data size in response to a write command for the management data; reading the management data from the management data storage area in response to a read command for the management data, and verifying the read management data.

[0022] The simulator and simulation method for storage devices provided in this application establish metadata records for each data unit of the storage device to be simulated, including a unit identifier field, a write bitmap field, and a modification count field. This records the identification information of the data unit, the write status of each smallest data unit, and the total number of modifications, replacing the storage of the actual data content within the data unit. This achieves an order-of-magnitude reduction in memory space usage compared to full-scale simulation, significantly reducing hardware resource consumption and enabling the simulation of large-capacity storage devices to run on ordinary development equipment, thus significantly saving development costs. Furthermore, by performing collaborative verification of the unit identifier field, write bitmap field, and modification count field during the verification phase, core management logic defects in storage device firmware regarding address mapping, write integrity, and data versioning can be effectively covered without relying on comparison with actual data content, ensuring the accuracy and completeness of the simulation verification. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 This is a schematic diagram of the structure of a emulator for a storage device provided in one embodiment of this application.

[0025] Figure 2 A flowchart illustrating a simulation method for a storage device provided in one embodiment of this application.

[0026] Figure 3 A flowchart of a simulation method for a storage device provided in another embodiment of this application.

[0027] Figure 4 A flowchart of a simulation method for a storage device provided in another embodiment of this application.

[0028] Figure 5 A flowchart of a simulation method for a storage device provided in another embodiment of this application.

[0029] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0030] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of the invention. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to the present invention are not shown or described in the specification. This is to avoid obscuring the core parts of the invention with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0031] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0032] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship. Unless otherwise specified, the terms "connection" and "linkage" used in this application include both direct and indirect connections (linkages).

[0033] Before introducing the simulator provided in this application, the basic structure and working principle of the storage device to be simulated will be explained first, so as to facilitate the subsequent understanding of the simulation process of the storage device in this application.

[0034] Storage devices (such as NAND Flash, eMMC, SSD, UFS, etc.) are non-volatile data storage devices based on flash memory media. From a logical perspective, the host system accesses data in the storage device through Logical Block Addresses (LBAs). Each LBA corresponds to a minimum addressable unit, typically 512 bytes. The host can issue read commands, write commands, and other operation instructions to the storage device. These instructions carry the target logical address, indicating the starting position of the operation.

[0035] From a physical perspective, the flash memory medium inside a storage device consists of multiple physical blocks. Each physical block contains multiple storage pages. A storage page is the smallest physical unit for data read and write operations in the flash memory medium, and its size is typically 16KB or 18KB. Each storage page can be further divided into a data area and a spare area: the data area is used to store user data, and the spare area is used to store management data related to that storage page, such as error checking and correction codes, and mapping information from logical addresses to physical addresses.

[0036] Due to the physical characteristics of flash memory, it has the following operational limitations: write operations must be performed on a page-by-page basis; erase operations must be performed on a block-by-block basis, and pages must be erased before new data can be written; each physical block has a limited erase lifetime. To address these physical limitations and provide the host with an efficient logical address access interface, the storage device runs firmware that implements a flash translation layer. This layer dynamically maps the logical block addresses used by the host to the physical addresses (physical blocks and pages) within the flash memory, while also performing background management tasks such as garbage collection, wear leveling, and bad block management.

[0037] In read / write operations on storage devices, when the host issues a write command, the firmware receives the command, parses the target logical address and the data to be written. Based on the flash memory translation layer's mapping algorithm, the firmware allocates one or more free physical storage pages for the target logical address, writes the data to the data area of ​​these physical storage pages, simultaneously writes corresponding management data to the spare area, and updates the internal address mapping table to record the correspondence between the target logical address and the physical address. When the host issues a read command, the firmware receives the command, parses the target logical address, queries the address mapping table to obtain the corresponding physical address, reads the data from the storage page containing that physical address, and returns it to the host.

[0038] Storage devices are managed internally in units of storage pages, while the host accesses them using a minimum addressing unit of 512 bytes. Therefore, the data area of ​​a storage page typically contains multiple minimum addressing units. For example, a 16KB storage page contains 32 minimum addressing units of 512 bytes. When managing mappings, firmware often further divides the data area within a storage page into smaller management units, such as 4KB units. In this case, a 16KB data area would contain four 4KB management units, each corresponding to eight consecutive minimum addressing units of 512 bytes.

[0039] When performing software simulation on the aforementioned storage devices, existing technologies typically employ a full-scale simulation approach. This involves allocating an equal amount of storage space in the emulator's memory for the entire storage device being simulated, storing all user data written by the host exactly as is. As the capacity of the storage devices being simulated continues to increase, this full-scale simulation approach consumes significantly more hardware resources from the emulator, resulting in high development costs.

[0040] Therefore, based on the structural characteristics and management methods of the aforementioned storage devices, this application proposes a simulation method that can effectively verify the core management logic of the storage device firmware with extremely low storage overhead. This method replaces the storage of data content by establishing metadata records that correspond one-to-one with the simulated storage data units, recording the identification information of the storage units, the write status of each smallest unit, and the total number of modifications. The corresponding metadata records are updated when responding to write commands and verified when responding to read commands. This allows for the verification of the correctness of the core management logic of the storage device firmware, such as address mapping, write integrity, and data version, without storing the actual data content.

[0041] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0042] Figure 1 This is a schematic diagram of the structure of a emulator for a storage device provided in one embodiment of this application. Figure 1 As shown, the emulator for storage devices provided in this embodiment includes at least a memory 110 and a processor 120.

[0043] In this embodiment, memory 110 is used to store programs or instructions for implementing simulation testing, as well as metadata record sets. The memory may include volatile memory and / or non-volatile memory. Volatile memory may be, for example, random access memory (RAM), including static random access memory (SRAM), dynamic random access memory (DRAM), etc., used to cache metadata records and temporary data during program execution during simulation. Non-volatile memory may be, for example, read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD), used to persistently store simulation programs, metadata records, and simulation state snapshots, etc. The memory can be connected to the processor via an internal bus, or it can be partially located within the processor, such as as an on-chip cache or register file. During simulator operation, since the size of the metadata record set is much smaller than the user data capacity of the storage device to be simulated, the space allocated in the memory for the metadata record set is only in the tens to hundreds of MB range, which can support the simulation of storage devices in the hundreds of GB or even TB range. This is one of the significant advantages of this application in terms of hardware resource consumption compared to the traditional full simulation method.

[0044] The processor executes stored programs or instructions to perform simulation testing of the storage device. The processor can be a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The processor can be an integrated circuit chip with signal processing capabilities, which reads and executes program instructions from memory to perform various simulation operations in the embodiments of this application, such as updating metadata records in response to write commands and verifying metadata records in response to read commands. In actual deployment of the simulator, the processor can be integrated into the development host or server, or it can serve as the control core on a standalone simulation accelerator card; this application does not impose specific limitations in this regard.

[0045] The emulator provided in this embodiment can be used in any of the following devices: NAND Flash, solid-state drive (SSD), embedded multimedia memory card (eMMC), or universal flash storage (UFS), or other storage devices that use flash media and manage logical address to physical address mapping through firmware.

[0046] While the aforementioned storage devices differ in physical interfaces, packaging, and specific application scenarios, their internal architectures all include flash memory media and a firmware layer responsible for flash memory management. The firmware layer must implement core management logic such as address mapping, garbage collection, and wear leveling. The simulator provided in this application is a tool for simulating and verifying this type of firmware management logic. It uses metadata records to replace actual data content in its simulation method, which is independent of the specific device's interface protocol and physical specifications. Therefore, it is universally applicable to firmware development and testing scenarios for the aforementioned storage devices.

[0047] When simulating a storage device, the storage space is divided by the emulator into multiple data units with a preset granularity. The "preset granularity" refers to the size of the basic management unit used by the emulator when managing user data on the simulated storage device. It is independent of the physical page size of the simulated storage device and is preset by the emulator as needed. In a specific example, this preset granularity is set to 4KB. Each data unit contains multiple minimum data units, which are the smallest granularities addressed by data read / write operations, typically 512 bytes. Thus, a 4KB data unit contains eight 512-byte minimum data units.

[0048] In this embodiment, each metadata record in the metadata record set stored in the memory uniquely corresponds to a data unit. That is, the simulator no longer allocates 4KB of storage space for each data unit to store the actual user data; instead, it uses only a single, extremely concise metadata record to replace all the user data content for that data unit. Each metadata record includes three fields: a unit identifier field, a write bitmap field, and a modification count field.

[0049] The cell identifier field records the identification information of the corresponding data cell, which is determined based on the target logical address to which the data cell is written. Since each data cell contains multiple minimum data cells, and logical addresses are addressed in units of minimum data cells, a correspondence between the target logical address and the data cell identifier information can be established through calculation. Specifically, when the preset granularity is 4KB and the minimum data cell is 512 bytes, the identifier information of the data cell corresponding to the target logical address LBA X can be obtained by calculating the integer quotient of X divided by 8, i.e., cell identifier = floor(LBA / 8). This identifier information is stored in the cell identifier field during writing to mark which logical address range the data cell currently serves.

[0050] The write bitmap field is used to record the write status of each smallest data unit within the corresponding data unit. Each bit in the write bitmap field corresponds to a smallest data unit within the data unit. A bit value of the first value (e.g., 1) indicates that the corresponding smallest data unit has been written, and a bit value of the second value (e.g., 0) indicates that the corresponding smallest data unit has not yet been written. When the preset granularity is 4KB and the smallest data unit is 512 bytes, a data unit contains 8 smallest data units. Writing to the bitmap field requires 8 bits, which is exactly 1 byte. The position of each bit corresponds one-to-one with the offset position of the smallest data unit within the data unit.

[0051] The Modification Count field records the total number of times the corresponding data unit has been modified. "Modification" here includes operations that change the state of the data unit, such as writing to any smallest data unit within it or erasing it. Each modification operation increments the Modification Count field. The Modification Count field represents the current data version of the data unit; a higher value indicates more recent data.

[0052] In this embodiment, the processor is configured to perform update and verification operations on metadata records in response to input write and read commands.

[0053] Specifically, when the processor receives a write command, the command carries the target logical address and version information. The target logical address indicates the starting LBA for this write, and the version information can be the write sequence number corresponding to this write, or a globally incrementing sequence number maintained by the firmware to identify the version being written. Based on the target logical address, the processor determines the data unit corresponding to that target logical address according to a preset granularity partitioning rule, then accesses the metadata record corresponding to that data unit in memory and updates it.

[0054] When the processor receives a read command, the command carries the target logical address and expected version information. The expected version information indicates the version of the data expected to be obtained in this read, which is the version number assigned to the data during a previous write. The processor determines the corresponding data unit based on the target logical address, reads the metadata record corresponding to that data unit from memory, and verifies the unit identifier field, write bitmap field, and modification count field in the read metadata record. If the verification passes, the read operation is considered correct; if the verification fails, the read operation is considered incorrect, thereby capturing defects in firmware address mapping, data write integrity, or data version management.

[0055] Therefore, the emulator provided in this application replaces the complete storage of user data content in traditional full-scale simulation with a simplified metadata record structure. The emulator divides the storage space of the storage device to be simulated into multiple data units according to a preset granularity and maintains a metadata record for each data unit in the memory. Each metadata record fully captures the three major management attributes of the corresponding data unit—address attribution, write status, and data version—through three fields: unit identifier field, write bitmap field, and modification count field. In write command processing, the emulator only updates the values ​​of these three fields without saving any real user data; in read command processing, the emulator reads and verifies the consistency of these three fields to determine whether there are errors in the firmware's address mapping, write integrity, and data freshness. Given that the size of the metadata record is much smaller than the size of its corresponding data unit, the emulator achieves an order-of-magnitude reduction in storage space usage compared to the full-scale simulation method, thus enabling efficient simulation of large-capacity storage devices on ordinary development equipment.

[0056] In the above structure, the number of bits in each field of the metadata record can be flexibly configured according to the scale of the storage device to be simulated and the preset granularity of the data unit to obtain the optimal storage efficiency.

[0057] In some embodiments, for the cell identifier field, the number of bits is configured to be determined based on the total number of data cells, and the stored identifier information is a value corresponding to the integer quotient of the target logical address to be written to the data cell and the number of the smallest data cells.

[0058] In other words, the cell identifier field needs sufficient bit width to encode all possible data cell identifiers. If the storage space of the storage device to be simulated is divided into N data cells, then the number of bits in the cell identifier field is at least ceil(log2(N)). The specific identifier value stored in this field is obtained by dividing the target logical address by the minimum number of data cells contained in each data cell and taking the integer quotient. In this way, each data cell is assigned a unique logical identifier, which the simulator can use to determine whether the currently accessed data cell is consistent with the expectation.

[0059] For writing to a bitmap field, the number of bits is configured to be equal to the number of the smallest data units contained in each data unit.

[0060] The bitmap field is written using a bitmap method, where each bit independently corresponds to a smallest data unit within the data unit. A bit value of 1 indicates that the smallest data unit has been written, and 0 indicates that it has not been written. When the preset granularity of the data unit is 4KB and the smallest data unit is 512 bytes, a data unit contains 8 smallest data units, so writing to the bitmap field requires 8 bits. This one-to-one bitmap structure allows the emulator to accurately track the writing status of each smallest data unit within the data unit, and even if only a portion of the sectors in the data unit is written, it can still be accurately recorded and verified.

[0061] For the modification count field, the number of bits is configured to be determined based on the maximum number of times the data unit can be modified.

[0062] The modification count records the total number of times the corresponding data unit has been modified since the start of the simulation, including operations such as writing and erasing that change the state of the data unit. The bit width of the modification count field needs to be able to represent all values ​​from 0 to the expected maximum modification count. A reasonable maximum modification count can be set based on the type of storage device and its expected lifespan, and the number of bits required for this field can be determined accordingly.

[0063] In a specific embodiment, assuming the preset granularity of the data unit is 4KB and the size of the smallest data unit is 512 bytes, each data unit contains 8 smallest data units, and the number of bits written to the bitmap field is equal to 8, or 1 byte. The number of bits in the unit identifier field depends on the total capacity of the storage device to be simulated. If the storage device to be simulated has a capacity of 256GB, divided into approximately 67 million data units at a 4KB granularity, then the unit identifier field requires at least 26 bits, but can actually be 4 bytes, which satisfies both addressing requirements and facilitates processor-aligned access. The number of bits in the modification count field depends on the expected maximum number of modifications. Taking 3 bytes as an example, the maximum value that 3 bytes can represent is approximately 16.77 million, which is sufficient to cover the erase and write cycles of most flash memory devices throughout their entire lifecycle. Therefore, the total size of the metadata record is 4 bytes + 1 byte + 3 bytes = 8 bytes. Understandably, a 4KB data unit can be described using only 8 bytes of metadata. In this metadata record, bytes 0 to 3 correspond to the unit identifier field, which records the mapping table information; bits 0 to 7 of byte 4 correspond to the write bitmap field, indicating whether each of the 512 bytes within the 4KB data unit has been written; and bytes 5 to 7 correspond to the modification count field, recording the total number of writes and erases to the 4KB data unit. Compared to the 4096 bytes of user data per unit, the metadata record occupies only about one-five-hundredth of that, resulting in significant compression and a substantial reduction in the simulator's storage resource consumption. Simultaneously, the 4-byte unit identifier field supports unique addressing of massive amounts of data units, and the 3-byte modification count field provides ample version record space for each data unit, ensuring reliability during long-term, high-intensity simulation testing.

[0064] In some embodiments, when the processor updates the metadata record, it is configured to: write identification information determined based on the target logical address into the unit identification field, set the corresponding bit in the bitmap field of the smallest data unit corresponding to the target logical address, and write version information into the modification count field.

[0065] In other words, when the processor responds to a write command to update the metadata record, the update operation specifically includes writing to three fields separately. First, the processor calculates the identification information of the data unit to which the target logical address belongs, according to a preset partitioning rule, based on the target logical address carried in the write command, and writes this identification information into the unit identification field of the metadata record corresponding to the data unit. Taking a preset data unit granularity of 4KB and a minimum data unit of 512 bytes as an example, the processor calculates the integer quotient obtained by dividing the target logical address LBA X by 8, and writes it as the identification information into the unit identification field, thereby marking which logical address range the data unit currently serves. Second, the processor determines the specific minimum data unit actually written within the data unit based on the target logical address, that is, it calculates the remainder obtained by dividing LBA X by 8, and sets the bit position corresponding to the remainder in the bitmap field to 1 to mark that the minimum data unit has been written. Finally, the processor writes the version information carried in the write command into the modification count field, incrementing the value of this field to the current version, to record the total number of times the data unit has been modified up to this write. Through the above three update operations, the simulator completely records the address, write location, and version information of this write without storing any real user data, providing a basis for subsequent read verification.

[0066] In some other embodiments, when the processor verifies the read unit identifier field, write bitmap field, and modification count field, it is configured to: verify whether the identifier information in the unit identifier field is consistent with the identifier information determined based on the target logical address; verify whether the bit corresponding to the smallest data unit in the write bitmap field indicates that it has been written; and verify whether the value of the modification count field is equal to the expected version information; if any verification fails, the read operation is determined to be incorrect.

[0067] In other words, when the processor responds to a read command and verifies the read metadata record, its verification operation verifies the firmware management logic through a three-level, item-by-item check. The first level of verification targets the cell identifier field: the processor calculates the expected identifier information based on the target logical address in the read command, following the same rules as for write operations, and compares it with the actual identifier information stored in the cell identifier field of the metadata record. If the two are inconsistent, it indicates an error in the firmware's address mapping, causing the read operation to access the wrong data cell. The second level of verification targets the write bitmap field: the processor determines the smallest data cell corresponding to the target logical address and checks whether the bit corresponding to the smallest data cell in the write bitmap field has been set. If this bit is 0, it indicates that the smallest data cell has never been written, and the firmware has defects in write integrity or power-off recovery. The third level of verification targets the modification count field: the processor compares the expected version information carried in the read command with the actual value stored in the modification count field of the metadata record. If the two are not equal, it indicates that the read data version does not match the expectation, and the firmware may have errors in data freshness management, such as missed garbage collection or old data rollback. If any of the three checks fails, the processor determines that the read operation is erroneous, thus promptly identifying firmware defects. If all three checks pass, the read operation is deemed correct. This verification method does not require storing or comparing any real user data content; it only requires collaborative verification of three metadata fields to cover the correctness verification of the firmware in three core management logic aspects: address mapping, write integrity, and data version.

[0068] In other embodiments, in the simulator of any of the above embodiments, the memory is also used to store management data of the storage device to be simulated; the processor is further configured to perform simulation testing on the management data in full storage mode.

[0069] In the above embodiments, the simulator adopts differentiated simulation strategies for user data and management data. For the user data portion, the simulator uses metadata records instead of storing the actual data content to achieve significant compression of storage space. For the management data portion, the simulator allocates a dedicated storage area in the memory to save the complete content of the management data in a full-size storage manner, that is, it performs storage and read / write operations one-to-one with the original size of the management data.

[0070] The management data here refers to the data generated and maintained by the firmware during the operation of the storage device to be simulated, used to manage the flash memory media. Examples include data mapping tables, error checking and correction codes, power-off recovery logs, and bad block management information. Although this management data constitutes a small proportion of the total storage capacity, its data structure is complex and there are close dependencies between fields. Firmware processing of this management data involves complex parsing, updating, and verification logic. If metadata records are used as a substitute for these management data, the simulation fidelity may decrease due to the inability to reproduce the internal details of the management data, making it impossible to effectively verify the correctness of the firmware's processing of the management data.

[0071] Therefore, this embodiment retains the core advantage of significantly saving storage resources by compressing metadata for user data, while employing a full-volume storage method for management data to ensure that the firmware logic related to management data can be completely and accurately verified. This differentiated approach balances the dual requirements of simulation efficiency and simulation fidelity, enabling the simulator to provide a reliable simulation testing environment for all management functions of the storage device firmware while significantly reducing overall hardware resource consumption.

[0072] In summary, the emulator provided in any of the above embodiments constructs a compressed simulation structure centered on metadata records: the storage space of the storage device to be simulated is divided into multiple data units according to a preset granularity. A metadata record containing a unit identifier field, a write bitmap field, and a modification count field is maintained for each data unit in the memory. The processor updates this record during write operations and verifies it during read operations, thereby achieving verification of firmware address mapping, write integrity, and data version management with extremely low storage overhead. For user data, the emulator completely replaces the actual data content with metadata records, with each record occupying only a few bytes; for management data, the emulator retains its complete content in a full-size storage manner, ensuring the simulation fidelity of firmware logic related to management data. This differentiated simulation architecture of "compressed user data and full management data" balances simulation efficiency and reliability while significantly reducing overall hardware resource consumption, enabling firmware development and verification of large-capacity storage devices to be carried out efficiently in ordinary development environments.

[0073] Figure 2 This is a flowchart illustrating a simulation method for a storage device according to one embodiment of this application. Figure 2 As shown, the simulation method for storage devices provided in this embodiment can be applied to the emulator provided in any of the above embodiments. The simulation method specifically includes the following steps:

[0074] Step S210: Obtain the metadata record set; each metadata record in the metadata record set corresponds to a data unit with a preset granularity in the storage device to be simulated; each metadata record includes a unit identifier field, a write bitmap field, and a modification count field; the unit identifier field is used to record the identifier information of the corresponding data unit, and the identifier information is determined based on the target logical address to be written to the data unit; the write bitmap field is used to record the write status of each smallest data unit within the corresponding data unit; the modification count field is used to record the total number of times the corresponding data unit has been modified.

[0075] Before starting the simulation test, the simulator first acquires a metadata record set. Each metadata record in this set corresponds one-to-one with each data unit in the storage device to be simulated, divided according to a preset granularity. Each metadata record contains three fields: a unit identifier field, a write bitmap field, and a modification count field. The meaning and function of each field are the same as described in the aforementioned device embodiment and will not be repeated here. By establishing this metadata record set, the simulator provides a data foundation for record updates in subsequent write operations and record verification in read operations.

[0076] Step S220: In response to the write command, determine the data unit corresponding to the target logical address based on the target logical address and version information in the write command, and update the unit identifier field, write bitmap field and modification count field in the metadata record corresponding to the data unit.

[0077] When the emulator receives a write command, it first determines the data unit to which the target logical address belongs based on the target logical address and version information carried in the write command, and then locates the metadata record corresponding to that data unit. Subsequently, the emulator updates the three fields of the metadata record. The specific calculation method and update process are consistent with the processor's response to the write command in the aforementioned device embodiment, and will not be repeated here to avoid repetition. Through step S220, the emulator completely records the address attribution, write location, and version status of this write without storing real user data.

[0078] Step S230: In response to the read command, determine the data unit corresponding to the target logical address based on the target logical address and expected version information in the read command, read the metadata record corresponding to the data unit, and verify the read unit identifier field, write bitmap field, and modification count field.

[0079] When the emulator receives a read command, it determines the data unit to which the target logical address belongs based on the target logical address and the expected version information carried in the read command. It then reads the metadata record corresponding to that data unit from the metadata record set and verifies the read unit identifier field, write bitmap field, and modification count field. The verification logic is consistent with the verification operation of the processor responding to the read command in the aforementioned device embodiment. This includes verifying whether the identifier information in the unit identifier field is consistent with the identifier information determined based on the target logical address, verifying whether the bit in the write bitmap field corresponding to the smallest data unit indicates that it has been written, and verifying whether the value of the modification count field is equal to the expected version information. If any verification fails, the read operation is deemed incorrect. Through the coordinated verification of the three fields in step S230, the emulator can effectively verify the correctness of the firmware in terms of address mapping, write integrity, and data version management without comparing any real data content.

[0080] Figure 3 A flowchart illustrating a simulation method for a storage device provided in another embodiment of this application. Figure 3 As shown, in some embodiments, step S220 involves updating the cell identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data cell, specifically including:

[0081] Step S310: Write the identification information determined based on the target logical address into the unit identification field.

[0082] The metadata record update operation in step S220 can be further decomposed into three sub-steps, each corresponding to an independent update of one of the three fields in the metadata record.

[0083] First, the emulator writes the identification information determined based on the target logical address into the cell identifier field. This identification information is determined by converting the target logical address into a corresponding data unit identifier based on the preset data unit granularity and the smallest data unit size. Taking an example with a preset granularity of 4KB and a minimum data unit of 512 bytes, the emulator calculates the integer quotient obtained by dividing the target logical address LBA X by 8, and writes this quotient value as the identification information into the cell identifier field.

[0084] Step S320: Set the corresponding bit in the bitmap field of the smallest data unit corresponding to the target logical address.

[0085] Secondly, the emulator sets the corresponding bit in the write bitmap field for the smallest data unit corresponding to the target logical address. Specifically, the emulator determines the offset position of the smallest data unit to be written within the target logical address, and sets the bit in the write bitmap field corresponding to that offset position to 1 to mark that the smallest data unit has been written. Taking the above 4KB granularity, 512-byte smallest unit as an example, the emulator calculates the remainder obtained by dividing LBA X by 8, and sets the bit in the write bitmap field corresponding to that remainder to 1.

[0086] Step S330: Write the version information into the modification count field.

[0087] Finally, the simulator writes the version information carried in the write command into the modification count field, updating the value of the field to the current version, so as to record the total number of times the data unit has been modified up to this write.

[0088] It should be noted that the execution order of the above three sub-steps is not limited to this; for example, they can be executed in parallel or in other orders, as long as the update of the three fields can be completed in the process of responding to a single write command. Through the above three-step update operation, the simulator completely records the address, write location, and version status of this write without storing any real user data, providing a basis for verification in subsequent read operations.

[0089] Figure 4 A flowchart illustrating a simulation method for a storage device provided in another embodiment of this application. Figure 4 As shown, in some embodiments, step S230 verifies the read cell identifier field, the written bitmap field, and the modification count field, specifically including:

[0090] Step S410: Verify whether the identification information in the unit identification field is consistent with the identification information determined based on the target logical address.

[0091] In the above embodiment, the verification operation in step S230 can be further decomposed into four sub-steps. Through three-level item-by-item verification and unified error judgment, the correctness of the read operation can be fully verified.

[0092] First, a first-level check is performed to verify the correctness of the address mapping. Specifically, the simulator, based on the target logical address in the read command, calculates the expected identification information according to the same rules as for write operations, and compares it with the actual identification information stored in the cell identification field of the metadata record. If the two are inconsistent, it indicates that the firmware mapping table has directed the current read request to the wrong data cell, which actually stores data belonging to a different logical address. In other words, the firmware address mapping is incorrect, and the current read operation has accessed the wrong data cell, which actually stores data belonging to a different logical address range.

[0093] Step S420: Verify whether the bit corresponding to the smallest data unit in the bitmap field indicates that it has been written.

[0094] Secondly, a second level of verification is performed to check the integrity of the write operation. Specifically, the emulator determines the smallest data unit within the target logical address and checks whether the bit corresponding to the smallest data unit in the write bitmap field has been set to a valid state. If the bit is invalid, it indicates that the smallest data unit has never been written to, and there may be defects in the firmware's data write process or power-off recovery mechanism, such as the mapping table pointing to a blank area after power-off recovery.

[0095] Step S430: Verify whether the value of the modification count field is equal to the expected version information.

[0096] Next, a third level of verification is performed to check the freshness of the data version. Specifically, the emulator compares the expected version information carried in the read command with the actual value stored in the modification count field of the metadata record. If the two are not equal, it indicates that the read data version does not match the expectation, which may be due to the firmware's garbage collection operation missing older version data, or a version rollback occurring during mapping updates.

[0097] Step S440: If any check fails, the read operation is determined to be incorrect.

[0098] After completing the three-level verification, any failure in any of the above verifications indicates that the host will read incorrect data in a real storage device. Therefore, the emulator must classify it as a read operation error and return an error indication to the firmware. Only if all three levels of verification pass is the read operation considered correct. Failure in any of the three verification dimensions means that there is a defect in the corresponding management logic of the firmware, and that this defect has caused the read operation to obtain incorrect data results.

[0099] After determining that a read operation has failed, the emulator returns an error indication to the firmware so that developers can promptly identify and locate the defect. The error indication can include specific verification failure type information, such as indicating whether it is an address mapping error, incomplete write, or version mismatch, thereby helping developers quickly pinpoint the problem.

[0100] Conversely, only when all three levels of verification pass—that is, the values ​​of the cell identifier field, the corresponding bit in the written bitmap, and the modification count field all perfectly match the expected values—will the emulator determine that the read operation is correct. At this point, the emulator can return fixed simulated data or arbitrary data, because the verification results have proven that the firmware's management behavior in the three dimensions of address mapping, write integrity, and data version is correct; the data content itself is no longer relevant. This "AND" logic method ensures that the emulator, without storing the actual data content, can still achieve comprehensive verification of the firmware's core management logic with accuracy equal to or even better than a full data comparison.

[0101] It should be noted that the verification order of steps S410, S420, and S430 is not fixed. Their order can be adjusted according to actual implementation needs, or they can be partially executed in parallel, as long as the logical co-verification of the three fields is completed. This multi-level verification mechanism is based on the same principle as the processor verification operation in the aforementioned device embodiment, and will not be elaborated further.

[0102] Figure 5 A flowchart illustrating a simulation method for a storage device provided in another embodiment of this application. Figure 5 As shown, based on the above embodiments, the storage device simulation method provided in this embodiment may further include a differentiated processing step for management data. Unlike the strategy of using metadata record compression storage for user data, this embodiment uses full storage for management data in the simulation, specifically including:

[0103] Step S510: Obtain the management data of the storage device to be simulated.

[0104] It is important to clarify that management data and the aforementioned user data are fundamentally different in nature, source, and function. User data refers to the actual content data written by the host to the storage device, such as file system data blocks and persistent application data, which accounts for the majority of the storage device's capacity. Management data, on the other hand, refers to the data generated and maintained by the storage device firmware during operation to manage the flash memory media. Specifically, management data includes, but is not limited to, the following categories: a mapping table from logical addresses to physical addresses, used to record the current physical storage location corresponding to each logical address; error checking and correction codes, used to detect and repair bit errors generated during flash memory reads; a power-off recovery log, used to rebuild the consistency state of the mapping table after an abnormal power outage; a bad block management table, used to mark damaged physical blocks and isolate them to prevent continued use; and wear leveling statistics, used to record the number of erases for each physical block to guide data allocation strategies. This management data is generated and updated autonomously by the firmware in the background and is not directly exposed to the host, but its correctness directly determines whether the storage device can operate reliably.

[0105] Step S520: In response to the write command for management data, write the management data to the management data storage area of ​​the simulator according to the original data size.

[0106] When the emulator receives a write command for management data, the command carries the storage location information of the target management data and the content to be written. The emulator first locates the corresponding storage address within the management data storage area based on the storage location information. The management data storage area is a contiguous or segmented storage space pre-allocated by the emulator for management data in memory, with a total capacity equal to or slightly larger than the actual capacity of the management data area in the storage device to be simulated. For example, if the management data area occupies five percent of the total capacity in the storage device to be simulated, the emulator will allocate a correspondingly larger storage space for the management data storage area.

[0107] After locating the target storage address, the emulator writes the management data carried in the write command to the corresponding location in the management data storage area, byte by byte or word by word, exactly as it is in its original byte size. Here, "in its original size" means that the emulator does not perform any compression, truncation, or transformation on the management data, completely preserving the original data volume and internal structure, maintaining consistency with the storage method of management data in the real storage device. In this way, when the firmware subsequently needs to read, parse, or update this management data, the emulator can provide a management data view that is completely consistent with the real hardware, thereby ensuring that the simulation verification of firmware logic related to the management data has sufficient accuracy and reliability.

[0108] Step S530: In response to the read command for management data, read management data from the management data storage area and verify the read management data.

[0109] When the firmware performs operations such as address mapping lookup, garbage collection determination, and wear leveling decisions, it issues a read command to the emulator for management data. The read command carries the storage location information of the target management data and the desired data length. Upon receiving the read command, the emulator first locates the corresponding storage address in the management data storage area based on the storage location information, and then reads the specified length of management data starting from that address. Since the management data storage area stores the complete management data previously written to its original size, the emulator can return the requested management data as is.

[0110] After reading the management data, the emulator further verifies it. The verification method can be flexibly selected based on the specific type of management data and the firmware design requirements. A common verification method is data content comparison: the emulator can independently maintain a set of expected states for the management data, which is derived from the sequence of management data write commands previously issued by the firmware. The emulator compares the read management data with this expected state; if they match, the verification passes. Another verification method utilizes redundant check information within the management data: many storage devices contain checksum fields or cyclic redundancy check fields within their management data. The emulator can recalculate these check values ​​and compare them with the check values ​​stored in the management data to verify the integrity and correctness of the management data. In addition, the emulator can also perform logical consistency checks on the management data, such as checking whether the physical addresses in the mapping table are within a valid range and whether the erase count is monotonically increasing. If the verification finds errors or inconsistencies in the management data, the emulator returns an error indication to the firmware to help developers locate firmware defects related to the management data.

[0111] The fundamental reason why this embodiment adopts drastically different simulation strategies for user data and management data lies in the fundamental difference in the verification objectives of the two types of data during simulation. For user data, the core issues the simulator focuses on are: whether the firmware has written the data to the correct location, whether all the parts that should be written have been completely written, and whether the data read is the latest version. These three issues correspond to address mapping, write integrity, and data version freshness, respectively, all of which are management attribute issues and have nothing to do with whether the data content itself is 0x55 or 0xAA. Therefore, the simulator can completely replace the actual data content with three metadata tags: the cell identifier field, the write bitmap field, and the modification count field, and complete the verification by verifying these tags.

[0112] However, for management data, the core issues that simulators focus on are not only the aforementioned management attributes, but also the correctness of the management data content itself and the consistency of its internal structure. For example, whether a mapping relationship in the mapping table is correctly updated, whether the mapping table is completely rebuilt after a power outage, and whether error checking and correction codes are correctly calculated and matched all require parsing and comparing the specific content of the management data for verification. Furthermore, there are often complex dependencies between fields within the management data. For instance, the spare area of ​​a physical page may store both mapping information and error checking and correction codes, and these must maintain a corresponding relationship. If metadata compression is also used for management data, these internal structures and dependencies will be abstracted away, preventing the simulator from detecting defects in the firmware's management data processing.

[0113] From a storage space utilization perspective, this differentiated strategy still maintains extremely high overall storage efficiency. While management data requires full storage for simulation fidelity, its volume represents a very small proportion of the total storage device capacity. For example, in a typical NAND Flash memory page of 18KB, management data occupies only 2KB of spare space, approximately 11% of the total capacity. Even with full simulation of this data, its absolute storage requirement is still far less than the overhead of full simulation of user data. In contrast, after metadata compression, the storage requirement for user data drops dramatically from being equal to the device capacity to about one-five-hundredth. Combined, the overall storage space utilization of the emulator is still reduced by orders of magnitude compared to the full simulation method.

[0114] By combining the management data simulation process described in steps S510 to S530 with the user data simulation process described in steps S210 to S230, this application constructs a differentiated simulation method of "user data compression and full management data storage". This method significantly reduces overall hardware resource consumption, ensuring the verification capability of the firmware's core management logic through metadata verification for the user data portion, and ensuring the verification accuracy of its complex structure and internal logic through full storage for the management data portion. Thus, it achieves an optimal balance between simulation efficiency and reliability, providing an efficient and reliable simulation solution for firmware development and testing of large-capacity storage devices.

[0115] It should be noted that this document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components used to perform operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0116] While the principles herein have been illustrated in various embodiments, numerous modifications to the structures, arrangements, proportions, elements, materials, and components, particularly suited to specific environments and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document. Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the fundamental principles of the invention.

Claims

1. An emulator for a storage device, characterized in that, include: Memory is used to store programs or instructions for implementing simulation tests, as well as metadata record sets; Each metadata record in the metadata record set corresponds to a data unit with a preset granularity in the storage device to be simulated. Each metadata record includes a unit identifier field, a write bitmap field, and a modification count field. The unit identifier field records the identifier information of the corresponding data unit, which is determined based on the target logical address to which the data unit is written. The write bitmap field records the write status of each smallest data unit within the corresponding data unit. The modification count field records the total number of times the corresponding data unit has been modified. The processor is configured to, in response to an input write command, determine the corresponding data unit based on the target logical address and version information in the write command, and update the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit; and, in response to an input read command, determine the corresponding data unit based on the target logical address and expected version information in the read command, read the metadata record corresponding to the data unit, and verify the read unit identifier field, write bitmap field, and modification count field.

2. The emulator for a storage device according to claim 1, characterized in that, The number of bits in the unit identifier field is configured to be a number of bits determined based on the total number of data units, and the stored identifier information is a value corresponding to the integer quotient obtained by the target logical address of the data unit being written and the number of the smallest data units; the number of bits in the write bitmap field is configured to be equal to the number of the smallest data units contained in each data unit; the number of bits in the modification count field is configured to be a number of bits determined based on the maximum number of times the data unit can be modified.

3. The emulator for a storage device according to claim 1, characterized in that, When the processor updates the metadata record, it is configured to: The identification information determined based on the target logical address is written into the unit identification field, the corresponding bit of the smallest data unit corresponding to the target logical address is set in the write bitmap field, and the version information is written into the modification count field.

4. The emulator for a storage device according to claim 1, characterized in that, When the processor verifies the read unit identifier field, write bitmap field, and modification count field, it is configured as follows: Verify whether the identification information in the unit identifier field is consistent with the identification information determined based on the target logical address, verify whether the bit corresponding to the smallest data unit in the write bitmap field indicates that it has been written, and verify whether the value of the modification count field is equal to the expected version information; If any check fails, the read operation is considered to be erroneous.

5. The emulator for a storage device according to claim 1, characterized in that, The memory is also used to store management data of the storage device to be simulated; the processor is also configured to perform simulation testing on the management data in full storage mode.

6. The emulator for a storage device according to any one of claims 1-5, characterized in that, The storage device to be simulated includes any one of NAND Flash, SSD, eMMC, or UFS devices.

7. A method for simulating a storage device, characterized in that, include: Obtain the metadata record set; each metadata record in the metadata record set corresponds to a data unit with a preset granularity in the storage device to be simulated; Each of the aforementioned metadata records includes a unit identifier field, a write bitmap field, and a modification count field; The unit identifier field is used to record the identifier information of the corresponding data unit, which is determined based on the target logical address to be written to the data unit; the write bitmap field is used to record the write status of each smallest data unit within the corresponding data unit; the modification count field is used to record the total number of times the corresponding data unit has been modified. In response to a write command, based on the target logical address and version information in the write command, the data unit corresponding to the target logical address is determined, and the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit are updated; In response to a read command, based on the target logical address and expected version information in the read command, the data unit corresponding to the target logical address is determined, the metadata record corresponding to the data unit is read, and the read unit identifier field, write bitmap field, and modification count field are verified.

8. The simulation method for a storage device according to claim 7, characterized in that, The process of updating the unit identifier field, write bitmap field, and modification count field in the metadata record corresponding to the data unit includes: Write the identification information determined based on the target logical address into the unit identification field; Set the corresponding bit in the write bitmap field of the smallest data unit corresponding to the target logical address; Write the version information into the modification count field.

9. The simulation method for a storage device according to claim 7, characterized in that, The verification of the read unit identifier field, written bitmap field, and modification count field includes: Verify whether the identification information in the unit identification field is consistent with the identification information determined based on the target logical address; Verify whether the bit corresponding to the smallest data unit in the bitmap field indicates that it has been written; Verify whether the value of the modification count field is equal to the expected version information; If any check fails, the read operation is considered to be erroneous.

10. The simulation method for a storage device according to claim 7, characterized in that, Also includes: Obtain the management data of the storage device to be simulated; In response to the write command for the management data, the management data is written to the management data storage area of ​​the simulator according to the original data size; In response to a read command for the management data, the management data is read from the management data storage area, and the read management data is verified.

Images