Data check method, and device and storage medium

Abstract

Provided in the embodiments of the present disclosure are a data check method, and a device and a storage medium. The data check method comprises: when a read request is initiated, estimating a data version that is present on a target logic block, and using same as a first-type version; after the execution of the read request is ended, statistically compiling a data version that has occurred on the target logic block during the execution of the read request, and using same as a second-type version; and on this basis, when a data version actually read by the read request is the first-type version or the second-type version, determining that the read request passes the check.

Description

[0001] Data verification method, device and storage medium technical field

[0002]

[0001] The present disclosure relates to the field of storage technology, and more particularly to a data verification method, device, and storage medium.

[0003] In the field of storage, reading and writing data in a storage product, also known as an I / O operation, is a basic operation for storage products. After an I / O operation is initiated, it may have to cross multiple network environments or pass through multiple nodes before reaching the storage product. The redundancy of the link and the instability of the network greatly increase the possibility of data errors. Moreover, a storage product may be connected to multiple access terminals. Therefore, multiple threads often initiate random I / O operations in parallel, further increasing the possibility of data errors in the storage product.

[0004]

[0003] In the field of storage, linearizability is an important aspect of data correctness. Linearizability requires that any thread can read the most recently successfully updated data at any time.

[0005]

[0004] Currently, data verification schemes in the storage field usually only verify whether the data written into the storage product is original data, that is, verify the correctness of the content. However, this data verification scheme cannot verify whether the data read by different threads is linearly consistent. Therefore, it cannot guarantee the linear consistency of the data in the storage product.

[0006]

[0005] Various aspects of the present disclosure provide a data verification method, device, and storage medium for ensuring the linear consistency of data in a storage product.

[0007]

[0006] An embodiment of the present disclosure provides a data verification method applicable to a test component, wherein the test component issues a read request for testing to a target logical block in a storage product to be tested on demand. The method includes: when initiating any read request, estimating and recording the data version existing on the target logical block as a first type of version; after the execution of the read request is completed, counting the data versions that occurred on the target logical block during the execution of the read request as a second type of version; if the data version read by the read request belongs to the first type of version or the second type of version, determining that the read request has passed verification.

[0008]

[0007] Furthermore, when any read request is initiated, the data versions that may exist on the target logical block are recorded, including: when the read request is initiated, obtaining the data version being written contained in the writing version set from the verification meta information maintained for the target logical block; and obtaining the data version that has been written but is estimated to have not been overwritten contained in the completed version set from the verification meta information, to record as the data version that may exist on the target logical block.

[0009]

[0008] Furthermore, the test component also issues a test write request to the target logical block in the storage product to be tested as needed, and the method further includes: when initiating any write request, the target data version required to be written by the write request is added to the writing version set in the verification meta information, and the data version contained in the completed version set in the verification meta information is determined as the version to be overwritten corresponding to the write request; after the execution of the write request is completed, the target data version is moved from the writing version set to the completed version set in the verification meta information, and the version to be overwritten is deleted from the completed version set.

[0010]

[0009] Further, the method also includes: after the read request passes verification, determining other data versions in the first category of versions corresponding to the read request except the data version read by the read request as overwritten versions; and deleting the overwritten versions from the completed version set in the verification meta-information.

[0011]

[0010] Furthermore, the method further includes: if there is a target read request concurrent with the read request, after the read request passes verification, determining whether the first-type version corresponding to any target read request concurrent with the read request includes the data version read by the read request; if so, deleting the overwritten version from the first-type version corresponding to the target read request.

[0011] Further, the method further includes: when initiating the read request, creating a read context for the read request to record the first-type version, wherein the verification meta-information records the read contexts corresponding to each read request currently executing on the target logical block via a read context set; after the read request is executed, deleting the read context corresponding to the read request from the read context set; deleting the overwritten version from the first-type version corresponding to the target read request, including: deleting the overwritten version from the first-type version recorded in the read context of the target read request contained in the deleted read context set.

[0012]

[0012] Further, the method also includes: when initiating any write request, carrying the target data version required to be written by the write request in the target data requested to be written, so that a subsequent read request can determine the data version read; and / or, when initiating the write request, carrying the check code generated for the target data in the target data, so that the content correctness of the target logical block can be checked based on the check code after a subsequent read request occurs.

[0013]

[0013] Furthermore, the parity meta-information maintained for the target logical block includes the latest data version that increases with the write requests that are continuously initiated, and statistics are collected on the data versions that have occurred on the target logical block during the execution of the read request, including: recording the latest data version read from the parity meta-information when the read request is initiated as the starting version; recording the latest data version read from the parity meta-information when the read request is completed as the ending version; and counting the starting version, the ending version, and the data versions between the starting version and the ending version as the data versions that have occurred on the target logical block during the execution of the read request.

[0014]

[0014] Further, if the storage product to be tested has enabled the "exactly once" semantics, the method further includes: after the read request passes verification, determining the target write request corresponding to the data version read by the read request; moving the data version read by the read request from the writing version set to the completed version set in the verification meta-information, and deleting the data version already included in the completed version set when the target write request is initiated.

[0015]

[0015] Further, if the storage product to be tested supports a trim mechanism, the method further includes: when initiating the read request, estimating the trim version existing on the target logical block as a third type version, where the third type version is a subset of the first type version; after the execution of the read request is completed, if non-trim data is read, performing an operation of determining whether the data version read by the read request belongs to the first type version or the second type version; if trim data is read, determining that the read request has passed verification if the third type version is non-empty or if it is detected that a new trim version has occurred on the target logical block during the execution of the read request.

[0016]

[0016] Furthermore, the method further includes: when initiating the read request, obtaining, from the parity metadata maintained for the target logical block, a trim version being written and a trim version completed but estimated to be not yet overwritten, contained in a trim version set; and estimating the obtained trim version as the trim version existing on the target logical block.

[0017]

[0017] Further, the method further includes: after any trim write request is executed, adding the data version corresponding to the trim write request to the trim version set in the verification meta information, wherein the trim version set is a subset of the completed version set contained in the verification meta information, and the completed version set includes data versions that have been written but are estimated to have not been overwritten; if a data version deletion event occurs in the completed version set due to the completion of any write request, then if the data version deleted by the data version deletion event is in the trim version set, the data version is synchronously deleted from the trim version set.

[0018]

[0018] Furthermore, the method further includes: after any trim write request is completed, updating the latest completed trim version on the target logical block included in the parity meta information to the data version corresponding to the trim write request; recording the latest completed trim data version read from the parity meta information when the read request is initiated as the starting trim version; in the case where trim data is read, recording the latest completed trim data version read from the parity meta information at the end of the read request as the ending trim version; if the ending trim version is greater than the starting trim version or the trim version set in the parity meta information is non-empty at the end of the read request, determining that a new trim version has been monitored on the target logical block during the execution of the read request.

[0019]

[0019] The present disclosure also provides a computing device comprising a memory, a processor, and a communication component; the memory is configured to store one or more computer instructions; and the processor is coupled to the memory and the communication component to execute the one or more computer instructions to perform the aforementioned data verification method.

[0020]

[0020] The embodiment of the present disclosure also provides a computer-readable storage medium that stores computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the aforementioned data verification method.

[0021]

[0021] The embodiment of the present disclosure further provides a computer program product, comprising a computer program, which, when executed by one or more processors, causes the one or more processors to execute the aforementioned data verification method.

[0022]

[0022] In an embodiment of the present disclosure, a data verification scheme is provided, and it is proposed to use the data verification scheme to evaluate whether the storage product can guarantee linear consistency before the storage product is put into use. To this end, a user test read / write request can be issued to the target logical block of the storage product to be tested to simulate scenarios such as multi-threaded concurrent random read and write that may occur after the storage product to be tested is put into use. It is also proposed that when a read request is initiated, the data version that may exist on the target logical block is estimated as the first type of version; after the execution of the right read request is completed, the data version that occurred on the target logical block during the execution of the read request is counted as the second type of version; based on this, when the data version actually read by the read request belongs to the first type of version or the second type of version, it can be determined that the read request has passed the verification. In this way, if the storage product to be tested cannot guarantee linear consistency, it can be discovered in time because some read requests fail to pass the verification. Illustrations

[0023] The accompanying drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the accompanying drawings:

[0024]

[0024] FIG1a is a flow chart of a data verification method provided by an exemplary embodiment of the present disclosure;

[0025]

[0025] FIG1b is a schematic diagram of the types of storage products to be tested provided by an exemplary embodiment of the present disclosure;

[0026]

[0026] FIG1c is a schematic diagram showing a principle of verifying meta-information provided by an exemplary embodiment of the present disclosure;

[0027] FIG2 is a logic diagram of a practical application solution provided by an exemplary embodiment of the present disclosure;

[0028] FIG3 is a schematic diagram of a processing logic for a read request provided by an exemplary embodiment of the present disclosure;

[0029]

[0029] FIG4 is a schematic diagram of a processing logic for a write request provided by an exemplary embodiment of the present disclosure;

[0030] FIG5 is a schematic diagram of a processing logic for a trim write request according to an exemplary embodiment of the present disclosure;

[0031]

[0031] Figures 6a-6f are schematic diagrams of several exemplary application scenarios provided by the present disclosure;

[0032]

[0032] FIG7 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present disclosure.

[0033] To make the objectives, technical solutions, and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below in conjunction with specific embodiments of the present disclosure and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not all of the embodiments. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without creative effort are within the scope of protection of the present disclosure.

[0034]

[0034] Before describing in detail the technical solutions provided by the various embodiments of the present disclosure, several technical concepts involved in the present disclosure are briefly explained as follows.

[0035] Random and sequential read / write are two input and output methods used in storage products. Data occupies space in a storage product. For an empty storage product, data can be written sequentially. When some data is deleted, the storage location previously occupied by that data becomes vacant. Over time, the continuous writing and deleting of data creates many scattered storage locations. This results in a large data file being stored in many discontinuous storage locations. Reading and writing this type of data is considered random read / write.

[0036]

[0036] Multi-threaded concurrent random reading and writing can be understood as multiple threads concurrently issuing read and write operations to the same storage location in the storage product.

[0037] Linearizability, also known as atomic consistency or strict consistency, means that the operations performed by a thread will take effect at a certain point P between the program call and the return. Here, "take effect" means that it is perceived by all other concurrently running threads. As described in the background technology, linearizability requires that at any time, any thread can read the data of the most recently successfully updated data.

[0038] Currently, in the storage field, cyclic redundancy check (CRC) and other mechanisms are typically used to verify data in storage products during use. However, these data verification schemes can only verify content correctness, that is, whether the stored data is original data, and cannot verify whether the data in the storage product complies with linearizability. Linearizability is an important aspect of data correctness. If a storage product fails to ensure thread consistency, the read data will also contain errors.

[0039] To this end, this embodiment proposes a data verification method and utilizes this data verification scheme to assess whether a storage product can guarantee linearizability before it is put into production. In other words, the data verification method proposed in this embodiment can be understood as a performance testing scheme for storage products. In practical applications, only storage products that meet linearizability requirements after testing are put into production, effectively ensuring the linearizability of data in the storage product.

[0040]

[0040] The following describes in detail the technical solutions provided by various embodiments of the present disclosure in conjunction with the accompanying drawings.

[0041]

[0041] FIG. 1a is a flow diagram of a data verification method provided by an exemplary embodiment of the present disclosure. The method can be executed by a test component, which can be implemented as software, hardware, or a combination of software and hardware. The test component can be integrated into a computing device. The computing device can be a device that will subsequently need to actually use the storage product to be tested. It is worth noting that the computing device in this embodiment can be a physical machine, but can also be a virtual device such as a virtual machine, a bare metal server, or a container in a cloud computing scenario. This embodiment is not limited to this. In addition, FIG. 1b is a schematic diagram of the types of storage products to be tested provided by an exemplary embodiment of the present disclosure. Referring to FIG. 1b, the storage product to be tested in this embodiment can be a physical storage product such as a disk, but can also be a virtual storage product provided in a cloud storage scenario, such as various block storage products and object storage products, such as the cloud disk shown in FIG. 1b. This embodiment does not limit the product form of the storage product to be tested.

[0042] In this embodiment, referring to FIG. 1b , the test component provided in this embodiment can be installed in a computing device that requires the storage product under test. By running the test component, it is possible to evaluate whether the storage product under test can guarantee linearizability. In this embodiment, the test component can, on demand, issue a read / write request to a target logical block in the storage product under test for testing. The target logical block can be any unit storage location in the storage product under test. A logical block (or Logical Block) can be understood as a unit of space for data organization in a storage product. Correspondingly, there is also the concept of a Logical Block Address (LBA), which is carried in a read / write request. For example, in block storage products, the logical block size is typically 4KB. It should be understood that the logical block sizes in different storage products may vary, but this does not affect the adaptability of the data verification solution provided in this embodiment. The data verification method provided in this embodiment is adaptable to the logical block sizes of different storage products.

[0043] During research, the inventors discovered that linearizability defects mostly occur in the aforementioned multi-threaded concurrent random read / write scenario. Therefore, preferably, in this embodiment, the test component can simulate a multi-threaded concurrent random read / write scenario to issue read / write requests to the storage product under test. In practical applications, this scenario can be simulated by properly configuring the timing of issuing read / write requests.

[0044] Based on this, in this embodiment, the test component can perform data verification on each read request issued to the target logical block to evaluate whether the data read by each read request complies with linearizability. If the storage product under test cannot guarantee linearizability, some read requests will inevitably fail the verification. Therefore, in this embodiment, it is proposed to evaluate whether the storage product under test can guarantee linearizability by monitoring whether each issued read request passes the verification.

[0045] For ease of description, the data verification scheme provided in this embodiment will be described below from the perspective of any read request issued to a target logical block in the storage product under test. It should be understood that the same data verification scheme can be used to determine whether other read requests pass verification.

[0046]

[0046] Referring to FIG. 1a, the data verification method provided in this embodiment may include steps 100 to 102.

[0047]

[0047] Step 100: When any read request is initiated, the data version existing on the target logical block is estimated as the first type of version.

[0048]

[0048] Step 101: After the read request is executed, count the data versions that occurred on the target logical block during the read request execution as the second type of versions.

[0049]

[0049] Step 102: If the data version read by the read request belongs to the first type version or the second type version, it is determined that the read request passes the verification.

[0050]

[0050] In this embodiment, a global self-incrementing data version is maintained in the test component for the target logical block in the product to be stored. Here, global self-increment can be understood as a data overwrite occurs once on the target logical block due to a write request, and the data version is incremented.

[0051] During research, the inventors discovered that the essence of a read request is an operation, and therefore there will be corresponding invocation events and response events. From the perspective of a read request, an invocation event occurs when a read request is initiated, and a response event occurs when the read request is completed. Based on this, with reference to FIG1a, the data verification method provided in this embodiment is designed for the processing logic after the invocation event and response event corresponding to the read request, so as to verify whether the read request meets the linearizability requirement.

[0052] FIG2 is a logical diagram of a practical application solution provided by an exemplary embodiment of the present disclosure. Referring to FIG2 , in a practical application, the data verification method proposed in this embodiment can be adapted to provide two interfaces for read requests in the test component.

[0053]

[0053] The read preparation interface PrepareRead is called when an invocation event corresponding to a read request occurs, that is, when a read request is initiated.

[0054]

[0054] The read verification interface VerifyBuffer is called when a return (Response) event corresponding to a read request occurs, that is, it is called when the read request execution ends.

[0055]

[0055] By calling the above-mentioned read preparation interface and read verification interface, the processing logic inside these two interfaces can be implemented to realize the verification of the read request.

[0056]

[0056] Based on this, referring to FIG2 , in step 100, when a read request is initiated, the aforementioned read prepare interface may be called to estimate the data version existing on the target logical block as a first-type version. Here, the first-type version estimated for the target logical block is the data version that may exist on the target logical block when the read request is initiated. It will be understood that what is recorded in step 100 is essentially the data storage state of the target logical block at a time point, namely, when the read request is initiated or when the initiation event corresponding to the read request occurs. Based on this, this embodiment proposes recording the possible data versions existing on the target logical block for the read request in step 100. By proposing to record this type of data version, it is hoped that data versions that may be read by the read request and meet linearizability requirements can be discovered.

[0057]

[0057] In step 100, the data versions that may exist on the target logical block can be understood as data versions that have already appeared on the target logical block but may not have been overwritten by the time the read request is initiated. During research, the inventors discovered that write requests on the target logical block may be concurrent, and the execution time of different write requests is uncertain. Therefore, when a read request is initiated, it is impossible to determine which version of data is actually stored on the target logical block, and there may be more than one possibility. In this embodiment, it is assumed that the first-class versions recorded for the read request all meet the linearizability requirements. In other words, if the data version read by the read request belongs to the first-class version recorded for it, then the read request meets the linearizability requirements.

[0058] Continuing with FIG. 1a , in step 101, after a read request is executed, statistics are collected on the target logical block of data versions that occurred during the read request execution, as second-type versions. Continuing with the practical application solution provided in FIG. 2 , in step 101, after the read request is executed, the aforementioned read verification interface may be called to implement the processing logic in step 101.

[0059] It is understood that the statistics collected in step 101 essentially record the data storage state changes of the target logical block within a time period, which is the execution period of the read request. The execution of a read request takes time, and the execution period of a read request can be understood as the period between the occurrence of the read request and the completion of the read request execution. In this embodiment, statistics are collected in step 101 on the data versions that occurred on the target logical block during the execution of the read request. By collecting statistics on such data versions, it is possible to further explore data versions that may be read by the read request and meet the linearizability requirements.

[0060] During research, the inventors discovered that the data storage state on the target logical block changes dynamically. Therefore, a new data version may appear on the target logical block during the execution of a read request. In this embodiment, it is believed that the second type of version counted for the read request also meets the linearizability requirement. In other words, if the data version read by the read request belongs to the second type of version recorded for it, then the read request meets the linearizability requirement.

[0061]

[0061] It can be understood that, in this embodiment, based on the recording operation proposed in step 100 and the statistical operation proposed in step 101, the data version that may be read by the read request and meets the linear consistency requirement can be determined.

[0062] Based on this, referring to FIG. 1a, in step 102, it can be determined whether the data version read by the read request belongs to the corresponding first-category version or second-category version. If the data version read by the read request belongs to the first-category version or the second-category version, it can be determined that the read request passes verification. In other words, in step 102, if the read request passes verification, it indicates that the storage product under test can guarantee the linearizability of the read request.

[0063]

[0063] Based on the above-mentioned data verification concept provided by this embodiment, the test component can determine whether other read requests it issues to the target logical block pass the verification, and then can evaluate whether the storage product under test can guarantee linear consistency by monitoring whether each read request issued passes the verification.

[0064]

[0064] It can be seen that the data verification method provided in this embodiment can realize real-time linear consistency verification of the storage product under test. If it is found during the verification process that a read request issued to the storage product under test does not meet the conclusion of linear consistency, the data status of the storage product under test at that time can be conveniently recorded, thereby preserving on-site evidence.

[0065] In summary, this embodiment provides a data verification scheme and proposes utilizing this data verification scheme to assess whether a storage product can guarantee linearizability before it goes online. To this end, a user test read / write request can be issued to the target logical block of the storage product under test, simulating scenarios such as multi-threaded concurrent random reads and writes that may occur after the storage product under test goes online. Furthermore, it is proposed that when a read request is initiated, the data versions that may exist on the target logical block are recorded as first-category versions. After the read request is executed, the data versions that occurred on the target logical block during the execution of the read request are counted as second-category versions. Based on this, if the data version actually read by the read request belongs to the first-category version or the second-category version, the read request can be determined to have passed verification. In this way, if the storage product under test cannot guarantee linearizability, this can be promptly discovered due to some read requests failing verification.

[0066]

[0066] In the above or following embodiments, a variety of implementations can be used to record the first type of version for a read request. A preferred implementation is provided below.

[0067]

[0067] In this implementation, parity metadata can be maintained for the target logical block. FIG1c is a schematic diagram illustrating the principle of parity metadata provided by an exemplary embodiment of the present disclosure. Referring to FIG1c, in this embodiment, parity metadata can be maintained for each logical block included in the storage product under test. The parity metadata can be used to dynamically record various types of information related to the data storage status of the corresponding logical block. The information dynamically recorded in the parity metadata may include, but is not limited to: the latest data version on the target logical block; a set of writing versions for recording data versions currently being written; a set of completed versions for recording data versions that have been written but may not have been overwritten; and a read context set for recording the read contexts corresponding to each read request currently being executed on the target logical block.

[0068] Of course, this information is merely exemplary, and the verification meta-information may also dynamically record other information, and is not limited thereto. The dynamic recording mentioned here can be understood as the information recorded in the verification meta-information changing as the data storage status of the corresponding logical block changes. In this way, the verification meta-information can be used to present the real-time data storage status of the corresponding logical block.

[0069] Based on this, in this implementation, when a read request is initiated, the data version being written, included in the writing version set, and the data version that has been written but may not have been overwritten, included in the completed version set, are obtained from the parity metadata maintained for the target logical block. These obtained data versions are then recorded as the data versions that may exist on the target logical block. The data version being written can be understood as the data version being requested to be written by the currently executing write request. The data version that has been written but may not have been overwritten can be understood as the data version that has been written but for which there is no evidence of having been overwritten.

[0070]

[0070] Thus, in this implementation, when a read request is initiated, the data version that may exist on the target logical block can be determined as the first type of version by reading the writing version set*completed version set included in the verification meta information.

[0071] FIG3 is a schematic diagram of a processing logic for a read request provided by an exemplary embodiment of the present disclosure. Referring to FIG3 , an exemplary recording format for recording the first type of version for a read request is shown. When a read request is initiated, a read context can be created for the read request to record the first type of version corresponding to the read request. In actual applications, when a read request is initiated, the set of versions being written and the set of completed versions from the verification metadata can be copied to the read context corresponding to the read request to implement recording of the first type of version for the read request.

[0072]

[0072] Referring to Figure 3 , following the read context set dynamically recorded in the verification meta-information described above, after creating a read context for a read request, the test component can record the read context in the read context set in the verification meta-information. After the read request is executed, the test component can delete the read context corresponding to the read request from the read context set in the verification meta-information. This ensures that the read context set accurately records the read context corresponding to each read request being executed.

[0073] It is worth noting that the read context mentioned in FIG. 3 is merely an exemplary recording format for recording the first type version of a read request. This embodiment is not limited to this recording format for the first type version. Further examples are not provided here. Any recording format that can achieve accurate recording is applicable to this embodiment.

[0074] It is understood that in this implementation, the set of versions being written and the set of completed versions in the verification meta-information serve as important references for recording the first-category versions in the read request table. Therefore, this implementation also proposes finding evidence from multiple dimensions to improve the accuracy of the set of versions being written and the set of completed versions in the verification meta-information.

[0075]

[0075] In an exemplary evidence dimension, it is proposed that the initiation and termination timing of the write request can be used as evidence to timely update the writing version set and the completed version set of the verification meta-information.

[0076]

[0076] Based on this, under this exemplary evidence dimension: when initiating any write request, the target data version required to be written by the write request can be added to the version being written set in the verification meta information, and the data version contained in the completed version set in the verification meta information is determined as the version to be overwritten corresponding to the write request; after the execution of the write request is completed, the target data version is moved from the version being written set to the completed version set in the verification meta information, and the version to be overwritten is deleted from the completed version set.

[0077] During their research, the inventors discovered that a write request is essentially an operation, and therefore has corresponding invocation and response events. From the perspective of a write request, an invocation event occurs when a write request is initiated, and a response event occurs when the write request completes. Based on this, the inventors designed processing logic for the invocation and response events corresponding to write requests to support read request verification. Referring to FIG2 , in actual applications, two interfaces can be provided in the test component for write requests.

[0078]

[0078] Write preparation interface PrepareBuffer—called when an invocation event corresponding to a write request occurs, that is, when a write request is initiated.

[0079]

[0079] Write confirmation interface ConfirmBuffer—called when a return (Response) event corresponding to a write request occurs, that is, called when the write request execution ends.

[0080]

[0080] Among them, by calling the above-mentioned write preparation interface and write confirmation interface, various verification bases can be provided for read request verification based on the write request.

[0081]

[0081] FIG4 is a schematic diagram of a processing logic for a write request provided by an exemplary embodiment of the present disclosure. Referring to FIG4, the exemplary maintenance solution described above is shown.

[0082] As shown in FIG4 , when a write request is initiated, the aforementioned write preparation interface can be called to perform a round of updates on the verification meta-information. Referring to the aforementioned exemplary maintenance solution, when a write request is initiated, the target data version to be written by the write request can be added to the set of currently writing versions as one of the currently writing data versions. This ensures that the currently writing data version can be added to the set of currently writing versions in a timely manner. When a write request is initiated, a set of completed versions is also read from the verification meta-information. It should be understood that the set of completed versions contains data versions that have been written but may not have been overwritten when the write request was initiated. However, after the write request is executed, these data versions will inevitably be overwritten by the target data version corresponding to the write request.

[0083]

[0083] To this end, referring to FIG. 4 , after the write request is completed, the aforementioned write confirmation interface can be called to perform another round of updating of the verification meta information. Referring to the aforementioned exemplary maintenance solution, after the write request is completed, the target data version corresponding to the write request is moved from the writing-in-progress version set to the completed version set in the verification meta information. It is understood that after the write request is completed, the corresponding target data version is no longer the writing-in-progress data version, but has become a completed but potentially overwritten data version. Therefore, by promptly moving the target data version, the writing-in-progress version set in the verification meta information can be guaranteed to always accurately record the writing-in-progress data version. Furthermore, referring to the aforementioned exemplary maintenance solution, after the write request is completed, the to-be-overwritten versions are also deleted from the completed version set in the verification meta information. This ensures that data versions that have evidence of being overwritten (i.e., after the write request has completed) are promptly removed from the completed version set in the verification meta information, thereby ensuring that the completed version set always accurately records the completed but potentially overwritten data versions.

[0084]

[0084] It can be seen that in this exemplary maintenance scheme, a round of update operations on the verification meta-information is performed respectively when the write request is initiated and after the write request is completed, so that the data versions contained in the writing version set and the completed version set in the verification meta-information remain consistent with the execution status of the write request on the target logical block, thereby effectively improving the accuracy of the writing version set and the completed version set in the verification meta-information, and providing a more accurate reference basis for the recording operation of the first type of version.

[0085]

[0085] In another exemplary evidence dimension, it is proposed that the data version read by the read request can also be used as evidence to timely update the completed version set in the verification meta-information.

[0086]

[0086] Based on this, under this exemplary evidence dimension: after the read request passes the verification, the data versions that have been completed but estimated to have not been covered, except for the data version read by the read request, contained in the first type of version corresponding to the read request, can be determined as covered versions; and the covered versions can be deleted from the completed version set in the verification meta-information.

[0087] As mentioned above, the first-category version recorded for a read request when it is initiated includes data versions that have been written but may not have been overwritten. Here, the data versions actually read by the read request can be used as evidence to reassess the likelihood that each of the already written data versions in the first-category version has not been overwritten. Obviously, in addition to the data version read by the read request, the other already written data versions in the first-category version should have been overwritten. This is because a unique data version should exist on the target logical block at a given time point, and the data version read by the read request is either in its corresponding first-category version or in its corresponding second-category version. If the data version read by the read request is in its corresponding second-category version, it indicates that the data version read by the read request was written by a new write request that occurred during the execution of the read request. By the time the write request was completed, it must have overwritten all data versions that had already been written at the time the read request occurred. Therefore, this provides evidence that all already written data versions in the first-category version corresponding to the read request have been overwritten, and these data versions no longer have the possibility of being overwritten. However, if the data version read by the read request is in the corresponding first-category version, then the data version read by the read request is the only data version that has not been overwritten when the read request is initiated. Therefore, this provides evidence to prove that, except for the data version actually read by the read request, all other written data versions in the first-category version corresponding to the read request have been overwritten and have lost the possibility of not being overwritten.

[0088]

[0088] In this way, the data version read by the read request actually provides evidence to support the determination of the overwritten version among the data versions originally included in the first type of version corresponding to the read request that have been written but may not have been overwritten.

[0089] During research, the inventors discovered that, under the requirement of linearizability, these overwritten versions should no longer be read by subsequent read requests. Therefore, they proposed that after a read request passes verification, the overwritten versions identified above are deleted from the set of completed versions in the verification meta-information. This ensures that the overwritten versions identified above are not recorded in the first-category versions corresponding to subsequent read requests. Thus, if a subsequent read request reads an overwritten version, it will fail verification, indicating that the storage product under test does not guarantee linearizability.

[0090]

[0090] It can be understood that after introducing the data version read by the read request as the update evidence of the verification meta-information, the test component can perform another round of update operation on the verification meta-information after the read request passes the verification. In this round of update operation, the completed version set in the verification meta-information can be updated, which can timely delete the data version that has been completed but has been overwritten in the completed version set of the verification meta-information, thereby ensuring that only the data version that has been completed but may not have been overwritten is retained in the completed version set of the verification meta-information, thereby ensuring the accuracy of verification of subsequent read requests.

[0091]

[0091] By combining the two exemplary evidence dimensions, the accuracy of the set of versions being written and the set of completed versions in the verification meta-information can be effectively guaranteed, thereby ensuring the accuracy of the first type of versions recorded for the read request, and thus improving the accuracy of the verification of the read request. However, it should be understood that the single exemplary evidence dimension can also improve the accuracy of the set of versions being written and the set of completed versions in the verification meta-information. Although there may be some loss of accuracy, if the number of read / write requests used for testing is sufficient, this loss can be compensated, and read requests that do not comply with linearizability can still be effectively detected. That is, the exemplary evidence dimensions described above can support the implementation of the technical solution of this embodiment either alone or in combination.

[0092]

[0092] In summary, in this implementation, the accuracy of the first type of version recorded for the read request can be verified by ensuring the accuracy of the version set being written and the completed version set in the verification meta-information.

[0093]

[0093] In addition, during the research process, the inventors discovered that concurrent read requests may occur on the target logical block. To this end, the present embodiment further proposes that: based on the data version read by the read request that has passed verification among the multiple concurrent read requests, the first-class version corresponding to the other concurrent read requests can be adjusted in a timely manner to provide a more accurate verification basis for these other read requests. It should be understood that these other read requests have already completed the recording operation on the first-class version based on the writing version set and the completed version set in the verification meta-information when they were initiated. The technical concept here is to modify the first-class version that has been recorded, and the modified first-class version will be used as the basis for the subsequent verification process.

[0094]

[0094] Based on this, following the aforementioned determination of the covered versions after the read request passes verification, the test component may also determine, when there are other concurrent read requests with the read request (for ease of distinction, the other concurrent read requests with the read request will be described as target read requests later. It should be understood that there may be one or more target read requests), that after the read request passes verification, for any target read request concurrent with the read request, whether the first-category version corresponding to the target read request contains the data version read by the read request; if so, these covered versions may be deleted from the first-category version corresponding to the target read request. The above logic may be executed for other target read requests to correct the first-category version of the relevant target read request. It is understandable that, under the linearizability requirement, after the covered versions are determined based on the data version read by the read request, other incomplete read requests concurrent with the read request should no longer read these covered versions. After this deletion operation, the first-category versions corresponding to other incomplete read requests concurrent with the read request that has already passed verification will no longer include these overwritten versions. Therefore, if these other incomplete read requests read any overwritten versions, they will not meet the linearizability requirements and will fail verification.

[0095]

[0095] Continuing from the previous description, the first-category version corresponding to a read request can be carried by a read context, which can be stored in a read context set in the verification meta-information. After the read request is executed, the read context corresponding to the read request is deleted from the read context set. Based on this, in an exemplary practical application, after a read request passes verification, the overwritten version can be deleted from each of the first-category versions recorded in the remaining read contexts in the read request set in the verification meta-information. In this way, when verifying other incomplete read requests concurrent with the read request that has passed verification, verification is performed based on the updated read context, thereby ensuring the accuracy of verification of these read requests.

[0096] In summary, the present embodiment provides a preferred implementation for recording the first type of version for a read request. In this implementation, verification meta information is maintained for the target logical block, and the verification meta information can be updated in a timely manner from various evidence dimensions to ensure that the verification meta information can accurately record the data storage status on the target logical block, thereby providing an accurate reference basis for recording the first type of version, and further ensuring the accuracy of the verification of the read request. It is worth noting that other implementations can also be used to record the first type of version for a read request in this embodiment, and are not limited to the above-mentioned preferred implementations. For example, the initiation time and end time of the write request on the target logical block can be monitored, so that when any read request is initiated, the first type of version is enumerated for the read request based on the monitored initiation time and end time of the write request. Other implementations will not be described in detail here. Any implementation that can accurately and comprehensively record the first type of version required in this embodiment can be adapted to this embodiment.

[0097]

[0097] In the above or following embodiments, various implementations may be used to calculate the second type of version for a read request. A preferred implementation will be provided below.

[0098]

[0098] In this preferred implementation, the verification meta-information mentioned in the above embodiment is adopted, and the latest data version on the target logical block contained in the above verification meta-information is mainly used.

[0099] Referring to FIG. 4 , during a round of updating operations on the verification meta-information when a write request occurs, the latest data version in the verification meta-information can be updated to the data version corresponding to the write request. This ensures that the latest data version in the verification meta-information is dynamically updated as write requests continue to occur. Based on this, this preferred implementation proposes using the latest data version in the verification meta-information to mine the data versions that occurred on the target logical block during the execution of a read request.

[0100]

[0100] To this end, in this implementation: the latest data version read from the verification meta-information when the read request is initiated can be recorded as the starting version; the latest data version read from the verification meta-information when the read request is completed can be recorded as the ending version; the starting version, the ending version, and the data versions between the starting version and the ending version can be counted as the data versions that occurred on the target logical block during the execution of the read request.

[0101]

[0101] The latest data version read from the verification metadata when a read request is initiated is the data version corresponding to the last write request on the target logical block at the time the read request is initiated. If the latest data version read from the verification metadata at the end of the read request execution is different from the latest data version read when the read request is initiated, it can be determined that a new write request has occurred during the execution of the read request. However, it is impossible to determine whether these write requests have been completed. Therefore, in this implementation, it is assumed that the data versions requested to be written by these write requests may all be read by the read request, which meets the linearizability requirement.

[0102]

[0102] In this way, based on the preferred implementation, the second type of version can be accurately and comprehensively counted for the read request, thereby providing an accurate judgment basis for the aforementioned step 102, and further ensuring the accuracy of the verification result of the read request.

[0103] It should be understood that, in this embodiment, other implementations may be used to count the second type of versions for read requests, and are not limited to the preferred implementation described above. For example, the initiation time and end time of a write request on a target logical block may be monitored, and after the read request is executed, the second type of versions may be enumerated for the read request based on the monitored initiation time and end time of the write request. Other implementations will not be described in detail herein; any implementation that can accurately and comprehensively record the second type of versions required in this embodiment is applicable to this embodiment.

[0104]

[0104] In the above or following embodiments, it is also proposed to transform the data structure of the target data requested to be written by the write request, so as to provide support for the data verification solution in this embodiment through the transformed data structure.

[0105]

[0105] In this embodiment, based on the transformation of the data structure, the target data requested to be written in the write request may include but is not limited to: the target data version to be written; the write location; the version to be overwritten; random data used for write testing; a set of data versions that have been written; and a check code generated for the random data, such as a CRC.

[0106]

[0106] As mentioned above, in this embodiment, a global self-incrementing data version is set for the target logical block. Therefore, when a write request occurs, the corresponding data version can be obtained according to the global self-incrementing mechanism.

[0107] Based on this, referring to FIG. 4 , when a write request occurs, the target data version corresponding to the write request can be included in the target data being written. In this way, if a subsequent read request reads the target data from the target logical block, the data version can be parsed from the target data and used as the data version read by the read request. This provides an implementation basis for the aforementioned step 102. In step 102, after the read request is executed, the data version can be parsed from the read data and used as the data version read by the read request.

[0108]

[0108] Further, referring to FIG4, when a write request occurs, a check code generated for the target data may also be carried in the target data, so that the target logical block can be checked for content correctness based on the check code after a subsequent read request is generated. The steps for content correctness verification are shown in FIG3. Referring to FIG3, after the read request is completed, a check code may be calculated for the read data and compared with the check code carried in the read data. If they are consistent, the content correctness verification of the target logical block passes.

[0109]

[0109] Further, referring to FIG4, when a write request occurs, the write position can also be carried in the target data for atomicity verification after a subsequent read request occurs. Referring to FIG3, after the read request is executed, the actual read position and the write position carried in the read data can be compared. If they are consistent, it is determined that the read request has passed the atomicity verification.

[0110] In summary, in this embodiment, based on the data structure modification of the target data requested by the write request, a variety of information can be included in the target data to support the data verification scheme of this embodiment. Furthermore, in addition to the aforementioned linearizability verification dimension, content correctness verification and atomicity verification can also be used as optional verification dimensions in the read request verification process based on information such as the write location and checksum carried in the target data. This allows for more comprehensive verification of read requests and, in turn, a more comprehensive evaluation of the performance of the storage product under test.

[0111]

[0111] It is also proposed in the above or following embodiments that the test component can be used to evaluate whether the storage product to be tested supports exactly once semantics.

[0112]

[0112] During the research process, the inventors found that some storage products to be tested declared that the "exactly once" semantics were enabled, but they may not actually support the "exactly once" semantics. In this embodiment, by designing the processing logic of the test component, it is possible to evaluate whether the storage product to be tested supports the "exactly once" semantics.

[0113]

[0113] Among them, the exactly once semantics can be understood as when multiple write requests are repeatedly initiated, they will only be executed once on the storage device.

[0114]

[0114] In this embodiment, if the storage product to be tested has the exactly once semantics enabled, the data version read by the read request should be determined to be the data version that has been written and will not be written again.

[0115]

[0115] To this end, in this embodiment, the following processing logic is added to the test component to ensure accurate detection of read requests that do not comply with the "exactly once" semantics. This processing logic is as follows.

[0116] After the read request passes verification, the target write request corresponding to the data version read by the read request is determined; the data version read by the read request is moved from the writing-in-progress version set to the completed version set in the verification metadata, and the data version already included in the completed version set when the target write request is initiated is deleted. Regarding the data version already included in the completed version set when the target write request is initiated, based on the technical logic for determining the version to be overwritten for the write request when the write request is initiated, the version to be overwritten can be determined promptly after the target write request is initiated. For specific technical details, please refer to the previous description and will not be repeated here.

[0117] That is, after the read request passes verification, it is considered that the target write request corresponding to the data version read by the read request has taken effect but may not have yet been completed. In this case, the test component has not yet called the write confirmation interface in FIG. Therefore, the write confirmation interface is proactively called for the target write request to update the verification metadata in a more timely manner, without further waiting for the return event corresponding to the target write request to trigger the call of the write confirmation interface.

[0118] In summary, in this embodiment, based on the above-mentioned processing logic, a target write request corresponding to the data version read by the read request can be determined, and the verification meta-information update operation that should be performed after the write request is completed is actively performed on the target write request. In this way, during the execution of the target write request, if the read request reads the data version that has been overwritten by the target write request after the target write request has taken effect, the read request will not pass the verification. This can effectively detect read requests that do not comply with the exactly once semantics, thereby evaluating whether the storage under test supports the exactly once semantics.

[0119]

[0119] In the above or following embodiments, considering that some storage products to be tested may support a trim mechanism, a verification logic for trimming data is added to the test component.

[0120] A trim write request is a special write request that converts a specified logical block into invalid data. The trim write request may include the logical block address (LBA) and length. After the trim write request is executed, the data stored in the specified logical block becomes 0x00. Similarly, any read request generated after the trim write request is executed will read the trim data. The trim data does not contain any useful information but is instead all zeros.

[0121]

[0121] It is understandable that if a trim write request has occurred on the target logical block, then a subsequent read request may read trim data, and the trim data is all 0s, so it is no longer possible to determine the data version read by the read request, and the test component is no longer able to perform the aforementioned operation of determining whether the data version read by the read request belongs to its corresponding first-category version or second-category version.

[0122] FIG3 includes verification logic that can be used to trim data. Referring to FIG3 , when a read request is initiated, in addition to recording the first type of version and counting the second type of version for the read request, the trim version present in the target logical block is estimated as a third type of version. It should be understood that the trim version here is essentially still a data version, generated according to the global auto-increment mechanism mentioned above. That is, this embodiment does not set a separate version for the trim mechanism. Therefore, the third type of version is also a data version that may exist in the target logical block and is a subset of the first type of version. Moreover, referring to FIG3 , after the read request is executed, a judgment step is added to determine whether the data read by the read request is trim data. If the read request reads non-trim data, an operation and subsequent operations of determining whether the data version read by the read request belongs to the first or second category version can be performed to determine whether the read request passes verification. If the read request reads trim data, the read request can be determined to have passed verification if the third category version is not empty or a new trim version is detected on the target logical block during the execution of the read request.

[0123]

[0123] Based on this partial verification logic, although it is impossible to know the original version of the data read by the read request when the read request reads the trim data, it is possible to determine whether the trim data read by the read request is reasonable by recording the third type of version and monitoring whether a new trim version occurs during the read request.

[0124]

[0124] In a preferred implementation, the verification meta-information proposed in the aforementioned embodiment can be used to support recording the third type of version for a read request and monitoring whether a new trim version occurs during the execution of the read request.

[0125] To this end, this implementation proposes that the information dynamically recorded in the verification meta-information may further include: a trim version set for recording the trim version currently being written on the target logical block and trim versions that have been completed but are estimated to have not yet been overwritten (i.e., may not have been overwritten); and the latest completed trim version on the target logical block.

[0126]

[0126] Based on this, when a read request is initiated, the trim version set can be obtained from the verification meta information and recorded as the third type version corresponding to the read request.

[0127]

[0127] In this implementation, it is further proposed that the execution status of the trim write request can be used as evidence to ensure the accuracy of the trim version set in the verification meta information.

[0128] FIG5 is a schematic diagram of processing logic for a trim write request according to an exemplary embodiment of the present disclosure. Referring to FIG5 , after any trim write request is executed, the data version corresponding to the trim write request is added to the trim version set in the verification metadata. The trim version set is a subset of the completed version set included in the verification metadata. As previously described, the completed version set includes data versions that have been written but may not have been overwritten. If a data version deletion event occurs in the completed version set due to the completion of any write request, then if the data version deleted by the data version deletion event is in the trim version set, the data versions are synchronously deleted from the trim version set.

[0129] Referring to FIG. 5 , when a trim write request is initiated, since the essence of a trim write request is still a write request, the data version corresponding to the trim write request can be added to the set of versions being written in the verification meta information and a to-be-overwritten version can be determined for the data version as described in the previous embodiment. Furthermore, since the data to be written to the target logical block by the trim write request is all zeros, the data structure described in the previous embodiment is no longer used to construct the data to be written.

[0130] Continuing with FIG5 , after the trim write request is executed, in addition to moving the data version corresponding to the trim write request from the writing-in-progress version set to the completed version set and deleting the to-be-overwritten version from the completed version set as described in the previous embodiment, as shown in FIG5 , the data version corresponding to the trim write request is also added to the trim version set in the verification meta-information. This ensures that the trim version set in the verification meta-information can promptly include the trim version that has been written to the target logical block.

[0131]

[0131] Furthermore, referring to FIG. 5 , considering that other write requests may overwrite the data version corresponding to the trim write request, a method is proposed for coordinating deletion of the trim version set and the completed version set. Coordinating deletion means that when a data version in the trim version set is deleted from the completed version set, the data version is also deleted from the trim version set. This ensures that overwritten trim versions in the trim version set can be deleted promptly.

[0132]

[0132] Accordingly, the accuracy of the trim version set in the verification meta-information can be effectively guaranteed, thereby providing a reliable reference basis for the verification of trim data.

[0133]

[0133] This implementation also proposes that the latest completed trim version on the target logical block included in the aforementioned verification meta-information can be used as a basis to monitor whether a new trim version occurs on the target logical block during the execution of a read request.

[0134] Referring to FIG. 5 , after any trim write request is completed, the latest completed trim version on the target logical block contained in the aforementioned verification meta-information can be updated to the data version corresponding to the trim write request. This ensures the accuracy of the latest completed trim version in the verification meta-information. Furthermore, when a read request is initiated, the latest completed trim data version can be read from the verification meta-information and recorded as the starting trim version. After determining that the read request has read trim data, the latest completed trim data version read from the verification meta-information is recorded as the ending trim version. If the ending trim version is greater than the starting trim version or the trim version set in the verification meta-information is non-empty at the end of the read request, it is determined that a new trim version has occurred on the target logical block during the execution of the read request.

[0135]

[0135] Continuing to refer to FIG3, under the logical branch in which the read request reads the trim data, as mentioned above, it can be determined whether the third type version recorded by the read request is non-empty. If it is non-empty, it indicates that when the read request is initiated, there may be a trim version that has not been overwritten on the target logical block. Therefore, it is reasonable for the read request to read the trim data and it meets the linear consistency requirements. It can also be determined whether a new trim version occurs during the execution of the read request. If it occurs, the read request may read the trim data. Therefore, in this case, it is reasonable for the read request to read the trim data and it meets the linear consistency requirements.

[0136]

[0136] Continuing with FIG3, under the logical branch in which the read request reads the trim data, it is further proposed that the read request may also be verified for dimensions such as content correctness and atomicity. Atomicity refers to the indivisibility of a transaction: a series of operations within a transaction must either be completed or failed. It should be understood that since the trim data is all zeros, in this case, the read request may be assumed to have passed the verification for dimensions such as content correctness and atomicity. In addition, under this logical branch, the aforementioned processing logic for supporting exactly once semantics is still combined to evaluate whether the storage product under test supports exactly once semantics.

[0137] In summary, in this embodiment, if the storage product under test supports the trim mechanism, two logical branches can be provided for verifying read trim data and non-trim data, respectively. This embodiment primarily presents the implementation scheme in the logical branch for trim data. Thus, although it is impossible to determine the read data version for a read request that reads trim data, verification of such a read request can be completed based on the implementation scheme in the logical branch for trim data provided in this embodiment, thereby ensuring the accuracy of the read request verification and further evaluating whether the storage product under test supports linearizability.

[0138]

[0138] Figures 6a-6f are schematic diagrams of several exemplary application scenarios provided by the present disclosure. These schematic diagrams illustrate the timing relationship between read / write requests issued by the test component to the target logical block for testing, and also illustrate partial information contained in the verification metadata at the relevant time nodes. Furthermore, in these schematic diagrams, "write n" indicates a write request with the corresponding data version n; "read n" indicates a read request with the read data version n; and "trim write 5" indicates a trim write request with the corresponding data version 5.

[0139] FIG6 a illustrates the verification meta-information update process for a write request. Referring to FIG6 a, the test component can simulate thread 1 issuing a write request. Before the write request is initiated, the corresponding verification meta-information on the target logical block is shown in the leftmost dashed box in FIG6 a. When the write request is initiated, the write preparation interface can be triggered and the verification meta-information is updated to the state shown in the middle dashed box in FIG6 a. After the write request is executed, the write confirmation interface can be triggered and the verification meta-information is updated to the state shown in the rightmost dashed box in FIG6 a.

[0140] FIG6 b illustrates the verification meta-information update process for concurrent write requests from multiple threads. Referring to FIG6 b , the test component can simulate thread 1 and thread 2, and simulate the two threads issuing write requests, respectively. For the two concurrent write requests, the verification meta-information is updated when the two write requests are initiated and when they are completed. Referring to FIG6 b , it can be seen that after the write request is completed, the version to be overwritten determined for the write request is deleted from the set of completed versions in the verification meta-information.

[0141] FIG6c adds a read request to FIG6b. Referring to FIG6c, a read context is created when a read request is initiated to record the first type of versions (the set of versions being written and the set of completed versions in FIG6c) for the read request. When the read request is completed, it is detected that the version read by the read request is n, which is in the first type of versions. Therefore, the read request passes verification.

[0142] Figure 6d builds on Figure 6c by introducing a concurrent read request scenario. Referring to Figure 6c, the test component can simulate threads 1 and 2 to issue write requests, and can also simulate thread 3 to issue read requests. After read n+1 passes verification, the verification metadata is updated, and the read context for the concurrent read n is also updated. Therefore, after reading version n+1, subsequent read requests should not read the overwritten version n. If read n+1 reads version n, it will not meet the linearizability requirements, and read n will fail verification.

[0142]

[0143] Figure 6e illustrates a scenario with exactly-once semantics enabled. The test component can simulate threads 1 and 2 to issue write requests, and can also simulate thread 3 to issue read requests. Referring to Figure 6e , after the previous reads n and n+1 pass verification, the test component can proactively update the verification metadata based on the actual data versions read. Reads n and n+1 indicate that both versions n and n+1 have already completed a data write (i.e., written) to disk, and that version n has been overwritten by version n+1. Therefore, based on exactly-once semantics, no further write operations to version n will occur, and subsequent read requests should not read version n. However, the last read request in Figure 6e does read version n. Due to the proactive update of the verification metadata, when verifying the last read request, version n is no longer in the first or second category of versions for that read request, and therefore fails verification.

[0143]

[0144] Figure 6f illustrates a scenario where the storage device under test supports the trim mechanism. The test component can simulate threads 1 and 2 to issue the relevant information in Figure 6f on demand. Please refer to Figure 6f. After trim write n completes, the trim version set in the verification meta-information includes version n. However, a subsequent write n+2 occurs, overwriting the previous trim version 2 (read requests issued after write n+2 should no longer read trim data). Accordingly, the verification meta-information update operation performed after write n+2 completes deletes version n from the trim version set in the verification meta-information. Referring to Figure 6f, the read request that occurs after write n+2 reads the trim data. However, because the trim version set in the verification meta-information is empty (the third-category version recorded for this read request is empty) and the latest completed trim version in the verification meta-information has not changed (that is, no new trim version was generated during the execution of this read request), this read request fails verification.

[0144]

[0145] It should be understood that the application scenarios shown in Figures 6a-6f are exemplary only. The test component can also simulate various other application scenarios to more comprehensively evaluate whether the storage product under test can guarantee linearizability under various timing conditions, thereby more accurately outputting test conclusions for the storage product under test. Furthermore, the update process of the verification metadata involved in Figures 6a-6b can be referred to the relevant descriptions of the aforementioned embodiments and will not be repeated here.

[0145]

[0146] As shown in Figures 6a-6f, the data verification solution provided in this embodiment can verify each read request issued to the target logical block of the storage device under test to determine whether each read request meets the linearizability requirements. The verification results of the read requests can be used as a basis for evaluating whether the storage product under test can guarantee linearizability, thereby more accurately completing the evaluation of the storage product under test.

[0146]

[0147] It should be noted that some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation numbers such as 101 and 102 are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different sets, version types, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0147]

[0148] FIG7 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present disclosure. As shown in FIG7 , the computing device may include a memory 70 and a processor 71.

[0148]

[0149] A processor 71 is coupled to the memory 70 and is configured to execute a computer program in the memory 70 to issue a read request for testing to a target logical block in the storage product under test as needed, and is configured to: when initiating any read request, estimate the data version existing on the target logical block as a first-category version; after the read request is executed, count the data versions that occurred on the target logical block during the execution of the read request as a second-category version; and determine that the read request has passed verification if the data version read by the read request belongs to the first-category version or the second-category version.

[0149]

[0150] In an optional embodiment, when the processor 71 initiates any read request and estimates the data version existing on the target logical block, it can be specifically used to: obtain the data version being written contained in the writing version set from the verification meta information maintained for the target logical block when initiating the read request; obtain the data version that has been written but is estimated to have not been overwritten contained in the completed version set from the verification meta information; and record the obtained data version as the data version that may exist on the target logical block.

[0150]

[0151] In an optional embodiment, the test component also issues a test write request to the target logical block in the storage product to be tested as needed, and the processor 71 can also be used to: when initiating any write request, add the target data version required to be written by the write request to the writing version set in the verification meta information, and determine the data version contained in the completed version set in the verification meta information as the to-be-overwritten version corresponding to the write request; after the execution of the write request is completed, move the target data version from the writing version set to the completed version set in the verification meta information, and delete the to-be-overwritten version from the completed version set.

[0151]

[0152] In an optional embodiment, the processor 71 may also be used to: after the read request passes verification, determine other data versions contained in the first category of versions corresponding to the read request that have been written but may not have been overwritten, except for the data version read by the read request, as overwritten versions; and delete the overwritten version from the completed version set in the verification meta-information.

[0152]

[0153] In an optional embodiment, the processor 71 may further be configured to: if there is a target read request concurrent with the read request, after the read request passes verification, determine, for any target read request concurrent with the read request, whether the first-category version corresponding to the request contains the data version read by the read request; if so, delete the overwritten version from the first-category version corresponding to the target read request.

[0153]

[0154] In an optional embodiment, the processor 71 can also be used to: when initiating the read request, create a read context for the read request to record the first type of version, and record the read context corresponding to each read request being executed on the target logical block through a read context set in the verification meta information; after the execution of the read request is completed, delete the read context corresponding to the read request from the read context set; when the processor 71 deletes the overwritten version from the first type of version corresponding to the target read request, it can be specifically used to: delete the overwritten version from the first type of version of the read context record of the target read request contained in the read context set after deletion.

[0154]

[0155] In an optional embodiment, the processor 71 may further be configured to: when initiating any write request, carry the target data version in the target data requested to be written, so that a subsequent read request can determine the read data version; and / or, when initiating the write request, carry the check code generated for the target data in the target data, so that a content correctness check of the target logical block can be performed based on the check code after a subsequent read request occurs.

[0155]

[0156] In an optional embodiment, the parity meta-information maintained for the target logical block includes the latest data version that increases with the write requests that are continuously initiated. When the processor 71 counts the data versions that have occurred on the target logical block during the execution of the read request, it can be specifically used to: record the latest data version read from the parity meta-information when the read request is initiated as the starting version; record the latest data version read from the parity meta-information when the read request is completed as the ending version; and count the starting version, the ending version, and the data versions between the two as the data versions that have occurred on the target logical block during the execution of the read request.

[0156]

[0157] In an optional embodiment, if the storage product under test has enabled exactly once semantics, the processor 71 may further be used to: determine, after the read request passes verification, a target write request corresponding to the data version read by the read request; move the data version read by the read request from the writing version set to the completed version set in the verification meta-information, and delete the data version already included in the completed version set when the target write request is initiated.

[0157]

[0158] In an optional embodiment, if the storage product to be tested supports a trim mechanism, the processor 71 may further be configured to: when initiating the read request, estimate the trim version existing on the target logical block as a third-category version, where the third-category version is a subset of the first-category version; after the read request is executed, if non-trim data is read, determine whether the data version read by the read request belongs to the first-category version or the second-category version; and if trim data is read, determine that the read request has passed verification if the third-category version is non-empty and / or if it is detected that a new trim version has occurred on the target logical block during the execution of the read request.

[0158]

[0159] In an optional embodiment, the processor 71 may be further configured to: when initiating the read request, obtain, from the parity metadata maintained for the target logical block, a trim version being written and a trim version completed but possibly not yet overwritten, contained in a trim version set, to record them as trim versions that may exist on the target logical block.

[0159]

[0160] In an optional embodiment, the processor 71 may further be configured to: after any trim write request is completed, add the data version corresponding to the trim write request to the trim version set in the verification meta-information, wherein the trim version set is a subset of the completed version set contained in the verification meta-information, and the completed version set includes data versions that have been written but are estimated to have not been overwritten; if a data version deletion event occurs in the completed version set due to the completion of any write request, then if the data version deleted by the data version deletion event is in the trim version set, synchronously delete the data version from the trim version set.

[0160]

[0161] In an optional embodiment, the processor 71 may further be configured to: after any trim write request is completed, update the latest completed trim version on the target logical block included in the check meta information to the data version corresponding to the trim write request; record the latest completed trim data version read from the check meta information when the read request is initiated as the starting trim version; in the case where trim data is read, record the latest completed trim data version read from the check meta information at the end of the read request as the ending trim version; if the ending trim version is greater than the starting trim version or the trim version set in the check meta information is non-empty at the end of the read request, determine that a new trim version has been monitored on the target reverse edit block during the execution of the read request.

[0161]

[0162] Furthermore, as shown in FIG7 , the computing device further includes other components such as a communication component 72 and a power supply component 73. FIG7 schematically illustrates only some components, which does not mean that the computing device only includes the components shown in FIG7 .

[0162]

[0163] It is worth noting that, for the technical details in the above-mentioned embodiments of the computing device, reference can be made to the relevant descriptions in the aforementioned method embodiments. To save space, they will not be repeated here, but this should not cause any loss of the protection scope of the present disclosure.

[0163]

[0164] Accordingly, an embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which can implement the steps in the above method embodiment when executed.

[0164]

[0165] Accordingly, an embodiment of the present disclosure further provides a computer program product, which includes a computer program that can implement each step in the above method embodiment when executed.

[0165]

[0166] The memory described in FIG. 7 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, and the like. The memory can be implemented using any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0166]

[0167] The communication component in Figure 7 is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), or other technologies.

[0167]

[0168] The power supply assembly in FIG. 7 provides power to various components of the device in which the power supply assembly resides. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly resides.

[0168]

[0169] Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0169]

[0170] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine. The instructions, when executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.

[0171] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0170]

[0172] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0171]

[0173] It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product, or apparatus. In the absence of further limitations, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the recited elements.

[0172]

[0174] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0173]

[0175] The foregoing description is merely an embodiment of the present disclosure and is not intended to limit the present disclosure. Persons skilled in the art will readily appreciate that various modifications and variations are possible with the present disclosure. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present disclosure are intended to be within the scope of protection of the present disclosure.

Claims

Claims 1. A data verification method, wherein: Applicable to a test component, the test component issues a read request for testing on demand to a target logical block in a storage product under test. The method includes: when initiating any read request, estimating the data version existing on the target logical block as a first-category version; after the read request is executed, counting the data versions that occurred on the target logical block during the execution of the read request as a second-category version; and determining that the read request has passed verification if the data version read by the read request belongs to the first-category version or the second-category version.

2. The method according to claim 1, wherein: When any read request is initiated, estimating the data version existing on the target logical block includes: when the read request is initiated, obtaining, from parity metadata maintained for the target logical block, a data version being written that is included in a set of versions being written; obtaining, from the parity metadata, a data version that has been written but is estimated to have not yet been overwritten that is included in a set of completed versions; and recording the obtained data version as a data version that may exist on the target logical block.

3. The method according to claim 2, wherein: The test component also issues a test write request to the target logical block in the storage product under test as needed. The method also includes: when initiating any write request, adding the target data version required to be written by the write request to the writing version set in the verification meta information, and determining the data version contained in the completed version set in the verification meta information as the to-be-overwritten version corresponding to the write request; after the execution of the write request is completed, moving the target data version from the writing version set to the completed version set in the verification meta information, and deleting the to-be-overwritten version from the completed version set.

4. The method according to claim 2 or 3, wherein: The method further includes: after the read request passes verification, determining other data versions in the first category of versions corresponding to the read request, except for the data version read by the read request, as overwritten versions; and deleting the overwritten versions from the completed version set in the verification meta-information.

5. The method according to claim 4, wherein: Also includes: If there is a target read request concurrent with the read request, after the read request passes verification, for any target read request concurrent with the read request, determine whether the first-category version corresponding to it contains the data version read by the read request; if it does, delete the overwritten version from the first-category version corresponding to the target read request.

6. The method according to claim 5, wherein: The method also includes: when initiating the read request, creating a read context for the read request to record the first type of version, and recording the read context corresponding to each read request being executed on the target logical block through a read context set in the verification meta information; after the execution of the read request is completed, deleting the read context corresponding to the read request from the read context set; deleting the overwritten version from the first type of version corresponding to the target read request, including: deleting the overwritten version from the first type of version recorded by the read context of the target read request contained in the read context set after deletion.

7. The method according to claim 1, wherein: Also includes: When any write request is initiated, the target data version required to be written by the write request is carried in the target data requested to be written, so that subsequent read requests can determine the data version to be read; And / or, when the write request is initiated, the check code generated for the target data is carried in the target data, so that content correctness of the target logical block can be checked based on the check code after a subsequent read request occurs.

8. The method according to claim 1 or 2, wherein: The parity meta-information maintained for the target logical block includes the latest data version that increments with continuously initiated write requests. Counting data versions that occur on the target logical block during the execution of the read request includes: recording the latest data version read from the parity meta-information when the read request is initiated as a starting version; recording the latest data version read from the parity meta-information when the read request is completed as an ending version; and counting the starting version, the ending version, and data versions between the starting version and the ending version as data versions that occur on the target logical block during the execution of the read request.

9. The method according to claim 2 or 3, wherein: If the storage product under test has "exactly once" semantics enabled, the method further includes: after the read request passes verification, determining the target write request corresponding to the data version read by the read request; moving the data version read by the read request from the writing version set to the completed version set in the verification meta-information, and deleting the data version that was already included in the completed version set when the target write request was initiated.

10. The method according to claim 1, wherein: If the storage product to be tested supports the trim mechanism, the method further includes: when initiating the read request, estimating the trim version existing on the target logical block as a third type of version, where the third type of version is a subset of the first type of version; after the read request is executed, if non-trim data is read, determining the data version read by the read request An operation belonging to the first type version or the second type version; if trim data is read, then if the third type version is not empty or a new trim version is detected on the target logical block during the execution of the read request, it is determined that the read request passes the verification.

11. The method according to claim 10, wherein: Also includes: When the read request is initiated, the trim version being written and the trim version completed but possibly not yet overwritten included in the trim version set are obtained from the parity metadata maintained for the target logical block; and the obtained trim version is estimated as the trim version existing on the target logical block.

12. The method according to claim 11, wherein: The method further includes: after any trim write request is completed, adding the data version corresponding to the trim write request to the trim version set in the verification meta information, wherein the trim version set is a subset of the completed version set contained in the verification meta information, and the completed version set includes data versions that have been written but are estimated to have not been overwritten; if a data version deletion event occurs in the completed version set due to the completion of any write request, then if the data version deleted by the data version deletion event is in the trim version set, synchronously deleting the data version from the trim version set.

13. The method according to claim 11, wherein: The method further includes: after any trim write request is completed, updating the latest completed trim version on the target logical block included in the check meta information to the data version corresponding to the trim write request; recording the latest completed trim data version read from the check meta information when the read request is initiated as the starting trim version; in the case where trim data is read, recording the latest completed trim data version read from the check meta information when the read request is completed as the ending trim version; if the ending trim version is greater than the starting trim version or the trim version set in the check meta information is not empty when the read request is completed, it is determined that a new trim version has been monitored on the target logical block during the execution of the read request.

14. A computing device, wherein: comprising a memory, a processor, and a communication component; the memory being used to store one or more computer instructions; and the processor being coupled to the memory and the communication component, and being used to execute the one or more computer instructions, so as to execute the data verification method according to any one of claims 1 to 13.

15. A computer-readable storage medium storing computer instructions, wherein: When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the data verification method according to any one of claims 1 to 13.

16. A computer program product, wherein: The method comprises a computer program, which, when executed by one or more processors, causes the one or more processors to execute the data verification method according to any one of claims 1 to 13.

Images