A data storage method and system for distributed object storage

Abstract

This invention provides a data storage method and system for distributed object storage. The method includes: encoding the original data of the target object using erasure coding to generate a group of shards to be written, containing k data shards and m check shards; writing each shard to independent physical extended shards on different storage nodes, wherein the extended shards are stored hierarchically using record blocks and check information blocks; generating a write success response when the number of successfully written shards reaches a preset threshold (≥k and ≤k+m); and performing a sealing operation on the extended shards after writing, using the minimum logical commit length of each successfully written shard as the trust boundary, truncating excess data and locking write permissions. This application solves the dilemma of existing systems where some shards cannot be securely confirmed after writing, eliminates node blocking, balances write efficiency and data consistency, and improves the availability, integrity, and efficiency of the storage system.

Description

Technical Field

[0001] This invention belongs to the field of distributed storage technology, and in particular relates to a data storage method and system for distributed object storage. Background Technology

[0002] Distributed object storage systems commonly employ erasure coding to protect against data redundancy across nodes. In a typical erasure coding configuration, the original data is encoded into k data fragments and m parity fragments, totaling k+m fragments, which are written to different storage nodes. The mathematical properties of erasure coding ensure that the original data can be fully recovered using only any k usable fragments.

[0003] However, existing erasure coding write mechanisms generally require all k+m shards to be successfully written before returning a write completion response to the user. This full confirmation mode binds the write response latency to the processing speed of the slowest node. In a distributed environment, long-tail latency caused by factors such as network jitter, disk I / O blocking, and garbage collection is common. A single slow node or a faulty disk can block the entire business write stream, causing write availability to deteriorate sharply as the cluster size increases. This has become a core bottleneck restricting the application of large-scale erasure coding storage systems in high-concurrency business scenarios. Summary of the Invention

[0004] This application provides a data storage method and system for distributed object storage, which improves the write availability of erasure coding distributed object storage system while ensuring the consistency of written data.

[0005] This application discloses a data storage method for distributed object storage, including: The original data of the target object is erasure encoded to generate a group of fragments to be written, which contains k data fragments and m parity fragments; Each fragment in the fragment group to be written is written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node, and the extended fragment is stored in a hierarchical structure of record blocks and check information blocks. During the fragment writing process of the fragment group to be written, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated, wherein the minimum number threshold is greater than or equal to k and less than or equal to k+m. Perform a sealing operation on the extended shard after the write operation is completed. Use the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncate the data in the extended shard that exceeds the boundary, and lock the write permissions of the extended shard.

[0006] Optionally, a sealing operation is performed on the extended fragment after the write operation is completed. The sealing operation includes: Determine the logical commit length corresponding to the successfully written extended shard, where the logical commit length is the length of the logical data that has been persisted and confirmed by disk synchronization within the extended shard. The minimum logical commit length of each successfully written extended shard is used as the trusted boundary. Data exceeding the trusted boundary in each extended fragment is truncated; Lock write permissions for each extended shard.

[0007] Optionally, determining the logical commit length corresponding to the successfully written extended shard includes: Each storage node splits the received fragment into at least one record block, and each record block into at least one verification information block. The record block is a logical write unit within the extended fragment, and each record block uniquely corresponds to a sub-object within the fragment to be written. The verification information block is the smallest storage and verification unit within the record block. Each storage node writes the verification information block of each record block continuously to the corresponding extended fragment according to a preset logical offset; After each storage node completes the physical writing of the verification information block and synchronizes with the disk, it adds the data length of the verification information block written this time to the logical commit length of the corresponding extended shard and reports the synchronization completion status to the client. The logical commit length is the length of the logical data in the extended shard that has completed disk synchronization confirmation and persistence maintained by the storage node side. The client uses the minimum logical commit length of each extended shard in the successfully written extended shard as the trusted boundary, based on the synchronization completion status reported by all storage nodes.

[0008] Optionally, each storage node splits each record block into at least one verification information block, including: Each storage node splits each record block into at least one parity data unit; Each storage node generates a corresponding self-description header for each verification data unit. The self-description header includes: a verification value generated by performing integrity verification calculation on the verification data unit, a length field that records the data length of the verification data unit, and a type flag that identifies the position of the verification information block in its respective record block. Each storage node concatenates each verification data unit with its corresponding self-describing header to generate a corresponding verification information block.

[0009] Optionally, the data storage method further includes: When an anomaly is detected in the verification information block, the verification data unit in the verification information block is reconstructed by erasure coding using the verification data unit in other healthy segments in the same strip that corresponds to the verification information block, and the reconstructed verification data unit is rewritten into the corresponding extended segment.

[0010] Optionally, before erasure coding is performed on the original data of the target object, the following steps are also included: Determine if the size of the target object is less than a preset small object threshold; If the target object is a small object, the original data of multiple small objects are merged into an aggregated dataset, and the aggregated dataset is used as the original data for performing erasure coding. Assign a unique logical offset within the extended shard to each small object in the aggregated dataset, corresponding to the record block.

[0011] Optionally, before erasure coding is performed on the original data of the target object, the following steps are also included: Determine if the size of the target object is greater than or equal to a preset large object threshold; If the target object is a large object, the original data of the target object will be divided into multiple independent object blocks according to the preset block size; Each object block is assigned a unique object identifier, and each object block is treated as raw data for independent erasure coding.

[0012] Optionally, the data storage method is characterized by further comprising: When there are shards that have not returned write results, continuously monitor the response status of those shards. If the shard to be written returns a write failure response or no response within the preset return time threshold, the shard to be written is marked as a bad shard, and update information is sent to the metadata management module.

[0013] Optionally, after marking the fragment to be written as a bad fragment, the following steps are also included: In subsequent write scheduling, the positions of fragments marked as bad fragments will be excluded from the priority scheduling range; Request new extended shard resources from the management console to replace the extended shard corresponding to the bad shard.

[0014] Optionally, the data storage method further includes: Receive a read request for the target object and obtain the metadata triplet corresponding to the target object. The metadata triplet includes the extended fragment file identifier, logical offset, and actual length. Based on the extended fragment file identifier, logical offset, and actual length, read all verification information blocks within the target record block from the corresponding extended fragment; Perform integrity verification calculation on the verification data unit of each verification information block, and compare the calculation result with the verification value in the self-description header of the verification information block; If the check values ​​of all check information blocks match, concatenate the check data units of all check information blocks into the target object data and return it. If the verification values ​​of the verification information blocks are inconsistent, the corresponding verification information blocks are marked as abnormal and the background data repair process is triggered.

[0015] This application also discloses a data storage system for distributed object storage, characterized by comprising a management terminal and at least two storage nodes, wherein, The management terminal is configured to generate a shard group to be written. The shard group to be written is generated by erasure coding the original data of the target object. The shard group to be written includes k data shards and m check shards. Each fragment in the fragment group to be written is written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node. During the writing process, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated. The minimum number threshold is greater than or equal to k and less than or equal to k+m. The extended fragment is internally stored in a hierarchical structure of record blocks and verification information blocks. The storage node is configured to perform a sealing operation on the extended shard after the write operation is completed, using the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncating data in the extended shard that exceeds the boundary, and locking the write permission of the extended shard.

[0016] The dilemma described in the background art stems from the inability of existing systems to securely confirm write completion when only a portion of the fragments have been successfully written. This application addresses this problem through the following mechanism: As described in the above technical solution, after erasure coding generates k+m fragments, the system writes each fragment to an extended fragment on a different storage node. During the write process, when the number of fragments confirmed to have been successfully written reaches a preset minimum threshold (greater than or equal to k), a write success response is generated without waiting for the remaining fragments to complete. This process changes the write response latency from "depending on the slowest node" to "depending on the minSize-th fast node," thereby eliminating the blockage of the overall write process by a single slow or faulty node.

[0017] However, simply setting a threshold is insufficient to safely return early. Since some shards may have only completed partial writes or their processes may have crashed, their extended shards may contain inconsistent residual data exceeding the confirmed persistence boundary. Directly allowing subsequent reads will cause data consistency issues. This application addresses this problem through a sealing operation: after writing is complete, the system determines the logical commit length of each successfully written extended shard, i.e., the length of data that has been successfully persisted and confirmed by disk synchronization; the minimum logical commit length of each extended shard is taken as the trusted boundary; data exceeding this boundary in each extended shard is truncated and write permissions are locked. This process irrevocably solidifies the write consistency state among multiple nodes, ensuring that even in scenarios where some shards are delayed in being written to disk, all extended shards remain consistent within the trusted boundary and can be safely read.

[0018] The combination of the two mechanisms allows the system to balance write availability and data security, under the theoretical guarantee that erasure coding only requires any k fragments to recover. This is achieved by using mathematical redundancy to confirm successful writes in advance and by using sealing operations to ensure data consistency after early confirmation. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a data storage method for distributed object storage according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a data storage system for distributed object storage according to an embodiment of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0022] This application relates to a data storage method and system for distributed object storage. To facilitate understanding of the technical solution of this application, typical solutions in the prior art and their existing problems are first described.

[0023] In existing technology, a distributed object storage cluster using erasure coding redundancy protection is taken as an example. This cluster is deployed in three availability zones within the same city, containing dozens of storage nodes. The erasure coding is configured as EC(10,4), that is, k equals 10 data fragments, m equals 4 parity fragments, for a total of 14 fragments, which can tolerate the loss or damage of any 4 fragments.

[0024] When a user writes a 100MB video file to the cluster, the client performs erasure coding on the raw data of the video file, generating 10 data fragments and 4 parity fragments, each fragment being 10MB in size. The client then sends these 14 fragments in parallel to 14 extended fragments distributed across different storage nodes in three availability zones. Each extended fragment is an independent physical file on the disk of its corresponding storage node.

[0025] In this existing solution, the system mandates that all 14 shards must be successfully written to the disks of their corresponding storage nodes and that disk synchronization is completed before returning a write success response to the user. Under normal circumstances, all nodes can complete the write within tens of milliseconds, and the write latency perceived by the user is approximately tens to hundreds of milliseconds.

[0026] However, as the cluster size increases and the workload rises, long-tail latency issues become apparent. For example, at a certain moment, 13 out of 14 storage nodes complete the write and return success within 50 milliseconds, but the remaining node experiences write response latency of several seconds due to network jitter, disk I / O blocking, or Java Virtual Machine garbage collection pauses. According to the full confirmation rule, the entire write request must wait for the slowest node to complete, causing the user-perceived write latency to be extended to several seconds, which is dozens of times worse than normal. If this node experiences disk failure or process crash, the write request will continue to time out and retry until the number of retries is exhausted, directly impacting the write availability of the business.

[0027] The above example reveals a fundamental flaw in existing full-acknowledgment models: write response latency is determined by the processing speed of the slowest node, and an anomaly in a single node can block the entire business write stream. This application finds that the technical reason for this flaw lies not in the requirements of erasure coding mathematics, but in an engineering dilemma: if early return is allowed when only a partial shard succeeds, the storage node will simultaneously contain both persisted trusted data and dirty data remaining after partial write failures or process crashes. Due to the lack of a reliable persistence boundary to precisely define the boundary between the two, subsequent reads will face the risk of data inconsistency and silent errors. Therefore, existing technologies must make an extreme trade-off between write response latency and data security, sacrificing write availability to wait for all nodes to complete in exchange for boundary certainty. In other words, existing systems lack the ability to safely acknowledge write completion when a partial shard write is successful, because if early return is allowed, inconsistent dirty data may remain in the extended shards containing unsuccessful or partially successful shards. The system cannot distinguish this dirty data from the persisted trusted data during subsequent reads, thus causing data consistency problems.

[0028] Based on this, embodiments of this application provide a data storage method for distributed object storage, such as... Figure 1 As shown, it includes: S100: Encode the original data of the target object using erasure coding to generate a group of fragments to be written, which contains k data fragments and m parity fragments; S200: Write each fragment in the fragment group to be written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node, and the extended fragment is stored in a hierarchical structure of record blocks and check information blocks. S300: During the fragment writing process of the fragment group to be written, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated, wherein the minimum number threshold is greater than or equal to k and less than or equal to k+m. S400: Perform a sealing operation on the extended shard after the write operation is completed. Using the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncate the data in the extended shard that exceeds the boundary and lock the write permission of the extended shard.

[0029] This application provides a data storage method for distributed object storage. After erasure coding generates k+m fragments, the system writes each fragment to an extended fragment on a different storage node. During the write process, when the number of fragments confirmed to have been successfully written reaches a preset minimum threshold (greater than or equal to k), a write success response is generated without waiting for the remaining fragments to complete. This process changes the write response latency from "depending on the slowest node" to "depending on the minSize-th fast node," thereby eliminating the blocking of the overall write process by a single slow or faulty node.

[0030] However, simply setting a threshold is insufficient to safely return early. Since some shards may have only completed partial writes or their processes may have crashed, their extended shards may contain inconsistent residual data exceeding the confirmed persistence boundary. Directly allowing subsequent reads will cause data consistency issues. This application addresses this problem through a sealing operation: after writing is complete, the system determines the logical commit length of each successfully written extended shard, i.e., the length of data that has been successfully persisted and confirmed by disk synchronization; the minimum logical commit length of each extended shard is taken as the trusted boundary; data exceeding this boundary in each extended shard is truncated and write permissions are locked. This process irrevocably solidifies the write consistency state among multiple nodes, ensuring that even in scenarios where some shards are delayed in being written to disk, all extended shards remain consistent within the trusted boundary and can be safely read.

[0031] The combination of the two mechanisms allows the system to balance write availability and data security, under the theoretical guarantee that erasure coding only requires any k fragments to recover. This is achieved by using mathematical redundancy to confirm successful writes in advance and by using sealing operations to ensure data consistency after early confirmation.

[0032] In this embodiment of the application, erasure coding is performed on the original data of the target object to generate a shard group to be written, which includes k data shards and m check shards.

[0033] Specifically, erasure coding is a forward error correction coding technique. Its basic coding process is as follows: the original data is divided into k equal-length data segments. A linear transformation is performed using the coding matrix to generate m check segments of the same length as the data segments, resulting in a total of k+m segments. The mathematical properties of erasure coding guarantee that any k segments obtained from these k+m segments can be decoded using the corresponding decoding matrix to retrieve the complete original data. In practical applications, the values ​​of k and m can be configured according to the business requirements for redundancy and storage efficiency. Common configurations include EC(8,3), EC(10,4), and EC(16,4).

[0034] For example, using the aforementioned 100MB video file as an example, the client performs EC(10,4) encoding on the raw data of the video file, evenly dividing it into 10 data segments of 10MB each. Four 10MB check segments are then generated through linear encoding, resulting in a final group of 14 segments to be written. The 10 data segments are numbered 0 to 9, and the 4 check segments are numbered 10 to 13.

[0035] Each fragment in the fragment group to be written is written to an extended fragment distributed across different storage nodes. The extended fragment is an independent physical file on the storage node's disk. During the write process, when the number of fragments confirmed to have been successfully written reaches a preset minimum threshold, a response indicating successful write of the target object is generated. This minimum threshold is greater than or equal to k and less than or equal to k+m. The extended fragment internally uses a hierarchical structured storage of record blocks and checksum blocks.

[0036] It's important to note that an extended shard is a persistent container for sharded data on the storage node's disk. Each extended shard is an independent physical file on a designated disk of its corresponding storage node. Extended shards for different shards are distributed across different storage nodes and different physical disks to achieve data redundancy and isolation. Upon receiving a resource allocation request, the management system allocates an independent extended shard to each shard based on the health status of each storage node in the cluster, its availability zone, disk utilization, and load. It then returns a unique identifier for each extended shard, along with the network address and disk identifier of its respective storage node.

[0037] The minimum write threshold is a key parameter determining whether a write process can return a response to the user ahead of schedule. Its value is based on the principle that erasure coding mathematically requires only any k shards to fully recover the original data. Therefore, from an information theory perspective, as long as the number of successfully written shards reaches k, sufficient conditions for data recovery are met. In engineering practice, to provide a redundant buffer to handle potential silent shard corruption after successful writes, the minimum write threshold can be set to greater than or equal to k and less than or equal to k+m. For example, in an EC(10,4) configuration, the minimum write threshold can be set to 12 or 11. This means that when the 12th or 11th shard is successfully written, the client can return a write success response to the user without waiting for all 14 shards to complete. In a scenario where single-node write availability is 0.99, the probability of waiting for all 14 shards to succeed is approximately 0.86, while the probability of at least 11 successful writes exceeds 0.9999.

[0038] It's important to note that the criteria for determining a successful write operation are: after receiving the sharded data, the storage node completes the physical write operation and disk synchronization of the data in the extended shard, and then returns a write success response to the client. Here, disk synchronization refers to forcibly flushing the data from the file system page cache to the physical disk media; only at this point is the data considered persistent and reliable. If the write is considered successful after only being written to the page cache but before disk synchronization is complete, this data will be lost if the storage node experiences a power outage or process crash.

[0039] Hierarchical structured storage is the storage organization form within extended shards. As physical files, extended shards have their internal storage space organized into a hierarchical structure of record blocks and checksum blocks. A record block is the logical write unit within an extended shard, and each record block uniquely corresponds to a sub-object to be written to within the shard. A checksum block is the smallest storage and verification unit within a record block, carrying a self-describing header. This structured hierarchical design provides the foundation for subsequent fine-grained data verification and corruption location.

[0040] Perform a sealing operation on the expanded fragment after the write operation is complete. The specific execution process of the sealing operation is as follows: S010: Determine the logical commit length corresponding to the successfully written extended shard. The logical commit length is the length of the logical data that has been persisted and confirmed by disk synchronization within the extended shard.

[0041] It's important to note that logical commit length is a concept distinct from physical file length. Physical file length is recorded by the file system and reflects the number of bytes currently occupied by the file; logical commit length, on the other hand, is a metric maintained independently by the application layer of the storage node, only including the length of data that has been successfully persisted after disk synchronization. The difference between the two represents the data that has been written but not yet successfully synchronized to disk; the persistence of this portion of data is not yet guaranteed. For example, if the physical file length of an extended shard is 50MB, but the storage node has only performed disk synchronization on the first 40MB of data, then its logical commit length is 40MB, and the remaining 10MB of data is still in the page cache and has not yet been flushed to disk.

[0042] S020: The minimum logical commit length of each successfully written extended shard is used as the trusted boundary.

[0043] After collecting the logical commit lengths reported by all successfully written storage nodes, the client takes the minimum value as the trusted boundary. The trusted boundary serves the purpose of ensuring that data before this boundary has been confirmed as successfully synchronized on all successfully written nodes and can be safely read; data exceeding this boundary may not have been synchronized or may be inconsistent on some nodes, belonging to an untrusted dirty data area. For example, in a write operation involving 14 shards, 12 shards were successfully written, with logical commit lengths of 40MB, 41MB, 39MB, 40MB, 42MB, 38MB, 40MB, 41MB, 39MB, 40MB, 40MB, and 40MB respectively. The minimum value is 38MB, which is the trusted boundary. Data before 38MB has been synchronized on all 12 nodes; data exceeding 38MB may only have been synchronized on some nodes, and consistency cannot be guaranteed.

[0044] S030: Truncate data that exceeds the trusted boundary in each extended fragment.

[0045] For extended shards whose physical file length exceeds the trusted boundary, the storage node truncates the file to the trusted boundary and physically removes the excess data. Continuing with the previous example, for a node with a logical commit length of 41MB and a physical file length of 41MB, it is truncated to 38MB, and the last 3MB of data is removed. This removed data is data that has not been jointly acknowledged by all nodes. Even if some of this data is valid, it cannot be accepted from a global consistency perspective and must be removed to ensure complete data consistency across all nodes within the trusted boundary.

[0046] S040: Lock write permissions for each extended shard.

[0047] After completing the truncation operation, the storage node writes a seal flag to the file header or extended attributes of the extended fragment. This flag prohibits any subsequent write operations and converts the extended fragment to a read-only state. The data inside the sealed extended fragment is solidified as immutable, confirmed, and reliable data, available for read, verification, and repair operations, but no longer accepts new writes.

[0048] It's important to note that the sealing operation addresses a core challenge of existing technologies: in scenarios where partial shard writes to disk are allowed to lag or even fail, by determining the global minimum logical commit length as a trusted boundary, truncating excess data, and locking write permissions, the eventual consistent state of distributed multi-node writes is solidified in an irreversible manner. Establishing this boundary makes returning a write success early a safe and feasible operation, without worrying about encountering dirty or inconsistent data during subsequent reads.

[0049] The following describes the operation process of this application embodiment in conjunction with the complete process of writing the 100MB video file described above.

[0050] First, the client performs EC(10,4) erasure coding on the raw data of the 100MB video file, generating 14 fragments, each 10MB in size. The management system allocates 14 extended fragments to these 14 fragments, distributed across 14 different storage nodes in three availability zones. The client then sends the 14 fragments to their respective storage nodes in parallel.

[0051] After receiving the fragmented data, each storage node writes the fragment into the corresponding extended fragment. Assume the preset minimum write threshold is 12. When the 12th storage node completes disk synchronization and returns a write success response, the client determines that the minimum write threshold has been reached and returns a write success response to the upper-layer user. At this point, the writes on the remaining two nodes are still in progress or may fail, but this no longer blocks user requests.

[0052] Subsequently, the client collects the logical commit lengths reported by the 12 storage nodes that successfully wrote data, determines the minimum value as the trusted boundary, and sends a seal request to each node. Each storage node, based on the trusted boundary in the request, truncates data exceeding that boundary and locks write permissions for the extended shard. At this point, the data within the extended shard remains consistent within the trusted boundary and can be safely read. For the two nodes that failed to write data, the client marks them as bad shards and requests replacement resources from the management system.

[0053] In some embodiments, a sealing operation is performed on the extended fragment after the write operation is completed, the sealing operation including: Determine the logical commit length corresponding to the successfully written extended shard, where the logical commit length is the length of the logical data that has been persisted and confirmed by disk synchronization within the extended shard. The minimum logical commit length of each successfully written extended shard is used as the trusted boundary. Data exceeding the trusted boundary in each extended fragment is truncated; Lock write permissions for each extended shard.

[0054] In this embodiment of the application, the specific process by which the storage node splits the received fragments into record blocks and verification information blocks, and maintains the logical commit length, is as follows: Each storage node splits the received fragment into at least one record block, and each record block into at least one verification information block. A record block is the logical write unit within an extended fragment, and one record block uniquely corresponds to a sub-object within the fragment to be written; the verification information block is the smallest storage and verification unit within a record block.

[0055] Specifically, a shard to be written may correspond to a complete object of data, a collection of data aggregating multiple small objects, or a partial data block after a large object has been split. The storage node determines the boundaries and order of each record block based on the record block metadata list carried by the client in the shard write request, and splits the original shard data into corresponding record blocks according to the boundaries. Each record block carries its preset logical offset and data length information within the extended shard.

[0056] For example, in a scenario where 400MB of aggregated data is written, a 40MB shard contains 1000 small objects. The storage node splits the 40MB shard into 1000 record blocks based on the record block metadata list. Each record block corresponds to a small object, and the record block size ranges from 100KB to 1MB.

[0057] Each storage node writes the checksum blocks of each record block continuously to the corresponding extended shard according to a preset logical offset. It should be noted that these logical offsets are specified in advance by the client in the write request, and the storage node strictly follows these offsets to ensure that the arrangement order of the record blocks in the extended shard is completely consistent with the client's preset order, with no out-of-order, no overlap, and no gaps.

[0058] After each storage node completes the physical writing of the verification information block and synchronizes it with the disk, it adds the data length of the verification information block written this time to the logical commit length of the corresponding extended shard and reports the synchronization completion status to the client. The logical commit length is the length of the logical data that has been persisted and confirmed by disk synchronization within the extended shard maintained by the storage node.

[0059] For example, after a storage node completes the writing and disk synchronization of a batch of verification blocks, the total data length of these verification blocks is 2MB. The storage node adds this 2MB to the logical commit length and generates a synchronization completion status message to report to the client. The message carries the updated logical commit length value. After collecting the synchronization completion statuses reported by each node, the client takes the minimum logical commit length reported by all nodes as the global trust boundary.

[0060] The data storage method described above determines the logical commit length corresponding to a successfully written extended shard, including: Each storage node splits the received fragment into at least one record block, and each record block into at least one verification information block. The record block is a logical write unit within the extended fragment, and each record block uniquely corresponds to a sub-object within the fragment to be written. The verification information block is the smallest storage and verification unit within the record block. Each storage node writes the verification information block of each record block continuously to the corresponding extended fragment according to a preset logical offset; After each storage node completes the physical writing of the verification information block and synchronizes with the disk, it adds the data length of the verification information block written this time to the logical commit length of the corresponding extended shard and reports the synchronization completion status to the client. The logical commit length is the length of the logical data in the extended shard that has completed disk synchronization confirmation and persistence maintained by the storage node side. The client uses the minimum logical commit length of each extended shard in the successfully written extended shard as the trusted boundary, based on the synchronization completion status reported by all storage nodes.

[0061] Each storage node splits each record block into at least one verification information block, including: Each storage node splits each record block into at least one parity data unit; Each storage node generates a corresponding self-description header for each verification data unit. The self-description header includes: a verification value generated by performing integrity verification calculation on the verification data unit, a length field that records the data length of the verification data unit, and a type flag that identifies the position of the verification information block in its respective record block. Each storage node concatenates each verification data unit with its corresponding self-describing header to generate a corresponding verification information block.

[0062] In this embodiment of the application, the specific process by which the storage node splits the record block into a verification information block is as follows.

[0063] Each storage node splits each record block into at least one parity data unit. A parity data unit is a continuous segment of the original data in the record block, and its size is determined by a preset maximum data payload length. For example, if the preset maximum data payload length is 128KB, then a record block of 400KB is split into four parity data units, the first three of which are 128KB each, and the fourth is 16KB.

[0064] Each storage node generates a corresponding self-description header for each verification data unit. The self-description header consists of three parts: The first part is the check value generated by performing integrity check calculations on the check data unit. The integrity check calculation uses the Cyclic Redundancy Check (CRC) algorithm. The CRC algorithm treats the data to be checked as a binary polynomial, divides it by a fixed generator polynomial, and uses the remainder as the check value, appended to the data. This check value has a fixed length of 4 bytes. When the check data unit is read subsequently, the CRC calculation is re-executed, and the result is compared with the check value in the header. If they match, it indicates that no bit flips or corruption occurred during data storage; if they do not match, it indicates that the data within the check block has been silently corrupted.

[0065] The second part is the length field, which records the length of the check data unit. The length field is a 3-byte unsigned integer that precisely records the actual number of bytes in the check data unit. Since the record block is split according to a fixed maximum payload, only the length of the last check data unit may be less than the maximum payload; the length field identifies the actual valid data range of each check data unit.

[0066] The third part is the type flag, which identifies the position of the checksum block within its record block. The type flag occupies 1 byte and includes four types: complete block flag, indicating that the entire record block contains only one checksum block; first block flag, indicating that the checksum block is the first in the record block; middle block flag, indicating that the checksum block is located in the middle of the record block; and last block flag, indicating that the checksum block is the last in the record block. These four type flags enumerate all possible positions of the checksum block within the record block. By reading the type flags, the complete boundary of the record block and the order of the checksum blocks can be determined without additional indexing information.

[0067] Each storage node concatenates each check data unit with its corresponding self-description header to generate a check information block. The concatenation order is self-description header first, followed by check data units. The specific byte arrangement of the self-description header is as follows: the first 4 bytes are the check value, the next 3 bytes are the length field, and the last 1 byte is the type flag, for a total of 8 bytes.

[0068] In some embodiments, the data storage method further includes: When an anomaly is detected in the verification information block, the verification data unit in the verification information block is reconstructed by erasure coding using the verification data unit in other healthy segments in the same strip that corresponds to the verification information block, and the reconstructed verification data unit is rewritten into the corresponding extended segment.

[0069] In this embodiment of the application, when the system detects that a certain verification information block has a data anomaly, it initiates an accurate repair process for that verification information block.

[0070] Data anomaly detection methods include: performing cyclic redundancy checks on each verification information block when reading the target object and finding inconsistencies in the comparison; or finding verification failures when performing periodic integrity scans of extended shards in the background; or detecting disk sector read errors during the reading process on the storage node.

[0071] When a certain verification information block is determined to be abnormal, the system uses the verification data units in other healthy segments in the same strip that correspond to the abnormal verification information block to reconstruct the verification data units in the abnormal verification information block through erasure coding decoding.

[0072] The principle of erasure coding decoding and reconstruction is as follows: The parity data units at the same offset position within k healthy slices of the same write stripe are extracted. Together with the parity data units at the same position in each healthy slice, the original content of the parity data units in the abnormal parity information block can be deduced using the decoding matrix. This process only requires reading the corresponding data segments from the k slices. Each segment is roughly the same size as a data unit in the parity information block, for example, 128KB, rather than the entire data of the entire slice.

[0073] Taking the EC(10,4) configuration and verification information block with a maximum size of 128KB as an example, repairing a 128KB abnormal verification information block requires reading 128KB of data from each of the 10 healthy fragments at their corresponding offset positions, totaling approximately 1.28MB of data. However, using the traditional full reconstruction method, it would require reading 10 complete fragments (e.g., 10MB each), totaling 100MB of data. The data transfer volume required for repair is reduced from approximately 100MB to approximately 1.28MB, resulting in a repair amplification factor reduction of nearly 80 times.

[0074] After reconstruction, the system will rewrite the reconstructed verification data unit into the corresponding extended fragment, overwriting the original storage location of the abnormal verification information block, thus completing the repair.

[0075] In some embodiments, the data storage method further includes, before erasure coding is performed on the original data of the target object: Determine if the size of the target object is less than a preset small object threshold; If the target object is a small object, the original data of multiple small objects are merged into an aggregated dataset, and the aggregated dataset is used as the original data for performing erasure coding. Assign a unique logical offset within the extended shard to each small object in the aggregated dataset, corresponding to the record block.

[0076] In some embodiments, the data storage method further includes, before erasure coding is performed on the original data of the target object: Determine if the size of the target object is greater than or equal to a preset large object threshold; If the target object is a large object, the original data of the target object will be divided into multiple independent object blocks according to the preset block size; Each object block is assigned a unique object identifier, and each object block is treated as raw data for independent erasure coding.

[0077] In this application embodiment, differentiated preprocessing is performed on target objects of different sizes before erasure coding to optimize write performance and storage efficiency.

[0078] For handling small objects: Determine if the size of the target object is less than a preset small object threshold, typically set to 1MB. If the target object is a small object, merge the original data of multiple small objects into an aggregated dataset, and use this aggregated dataset as the original data for erasure coding.

[0079] Aggregating small objects before encoding transforms random writes of a large number of small objects into sequential writes of the aggregated dataset. In existing non-aggregation solutions, 10,000 small objects translate to 10,000 independent write requests to the storage system, generating a large amount of random I / O and resulting in low performance utilization of the mechanical disk. With the aggregation mechanism, the raw data of these small objects is concatenated into a contiguous aggregated dataset in the client's memory, followed by erasure coding and write distribution. This reduces the number of writes from tens of thousands to a level comparable to the number of shards, effectively improving write throughput.

[0080] Simultaneously, a unique logical offset is assigned to each small object within the aggregated dataset, corresponding to its record block, within the extended shard. The logical offset starts at zero and increments sequentially according to the order of the small objects. The starting offset of the preceding small object plus its data length equals the starting offset of the following small object, ensuring that all small object record blocks are arranged continuously within the extended shard without overlap or gaps.

[0081] For example, 1000 small archive storage objects with an average size of 400KB are aggregated into a 400MB aggregate dataset. A logical offset is assigned to each small object: the first small object starts at offset 0, has a length of 400KB, and occupies an offset ranging from 0 to 409599 bytes; the second small object starts at offset 409600, has a length of 1MB, and so on, up to the 1000th small object. This consecutive logical offset information is summarized into a record block metadata list, which is sent to the storage node along with the shard write request to guide the storage node's record block splitting and write operations.

[0082] For handling large objects: Determine if the size of the target object is greater than or equal to a preset large object threshold, typically set to 10MB. If the target object is large, divide its original data into multiple independent object blocks according to a preset block size. The block size is usually set in the several MB range, for example, 5MB. A 100MB video file is divided into 20 5MB object blocks.

[0083] Each object block is assigned a unique object identifier, and each object block is treated as independent raw data for erasure coding. The encoding and writing processes of each object block are independent and executed in parallel. When a large object is split, a single write failure only affects the retry of the corresponding object block, without needing to rewrite the entire 100MB. At the same time, the write results of each object block do not block each other, and slow nodes or failures of some object blocks do not affect the confirmation of successfully written object blocks.

[0084] In this embodiment, the purpose of object aggregation is to solve the problems of low write throughput and metadata bloat caused by the direct writing of massive numbers of small objects in distributed erasure coding storage. By merging multiple small objects into a continuous large dataset before writing, and then performing erasure coding and distribution on this dataset, a large number of random small block I / Os are transformed into a small number of sequential large block I / Os. Specifically, when massive numbers of KB-level small objects are independently erasure coded and written, each small object generates k+m fragments and triggers multiple network I / Os and disk I / Os. When the disk processes a large number of random small block writes, the seek and rotational latency far exceeds the data transmission time, resulting in extremely low throughput (mechanical disks may have less than 25% utilization). At the same time, maintaining metadata for each small object leads to an increase in the total amount of metadata, further slowing down the system. The aggregation mechanism of this application sets up a queue to sequentially concatenate a batch of qualified small object raw data into a continuous aggregate dataset in memory. This aggregate dataset is treated as a whole, and erasure coding is performed only once to generate k+m high-quality large fragments. During writing, it is a large block sequential write, which significantly reduces disk seek overhead. During aggregation, each small object is assigned a "record block" as its logical carrier, and the logical offset and length of this record block within the aggregated large shard are precisely recorded. During reading, based on the offset and length in the metadata, the record block corresponding to the small object can be accurately extracted from the corresponding shard and returned, ensuring that aggregation writes do not affect the independent reading of individual small objects. This significantly reduces the number of write I / O operations and metadata overhead without sacrificing the readability of individual objects, thus resolving the performance bottleneck of small object writes.

[0085] For example, for a 100MB video file divided into 20 object blocks, the client performs EC(10,4) encoding on each object block, generating 14 fragments, each approximately 512KB in size. The encoding and writing operations of the 20 object blocks are performed asynchronously and in parallel. Each object block independently performs a threshold check; when an object block reaches the minimum number threshold, the write operation is independently confirmed as successful. Once all 20 object blocks have been successfully written, the entire 100MB video file is marked as written successfully.

[0086] As can be seen, this application further organizes the fragment internally into a hierarchy of record blocks and checksum blocks. Each checksum block is a maximum of 128KB and carries a self-describing header containing a checksum calculated independently for the data in that block. This configuration moves the smallest checksum unit down from the file level to the checksum block level. Data integrity judgment no longer depends on the overall checksum, but is handled independently by each checksum block. During reading, the system checks the checksum header of each checksum block block by block. Once a block fails the checksum, the damaged location is immediately locked as that block. During repair, it is not necessary to rebuild the entire fragment. Only 128KB of data needs to be read from the corresponding offset positions of k healthy fragments in the same stripe. The original content of the damaged block can be reconstructed separately through erasure coding decoding, and these 128KB are written back to overwrite. The amount of data transmission required for repair is reduced from k × fragment size to k × 128KB. Combined with the above-mentioned trusted boundary settings, this ensures that a write success response is generated when the number of fragments confirmed to have been successfully written reaches a preset minimum threshold (greater than or equal to k) even with a low repair volume.

[0087] In some embodiments, the data storage method further includes: When there are shards that have not returned write results, continuously monitor the response status of those shards. If the shard to be written returns a write failure response or no response within the preset return time threshold, the shard to be written is marked as a bad shard, and update information is sent to the metadata management module.

[0088] The data storage method, after marking the fragment to be written as a bad fragment, further includes: In subsequent write scheduling, the positions of fragments marked as bad fragments will be excluded from the priority scheduling range; Request new extended shard resources from the management console to replace the extended shard corresponding to the bad shard.

[0089] In this embodiment of the application, for the shard to be written that has not returned a result during the writing process, the system executes an asynchronous listening and exception handling process.

[0090] When there are shards to be written that have not yet returned a write result, the client continuously listens to the response status of the shard to be written and can set a preset return time threshold, such as 30 seconds.

[0091] If the shard to be written returns a write failure response or no response within a preset return time threshold, the client marks the shard as a bad shard and sends update information to the metadata management module. The marking method can use a bad shard bitmap, where each binary bit corresponds to a shard slot within the shard group to be written to. A value of 1 indicates that the corresponding shard is a bad shard, and a value of 0 indicates a normal shard. The bad shard bitmap is a compact data structure that uses binary bits to indicate the location of abnormal shards.

[0092] In subsequent write scheduling, shard locations marked as bad are excluded from priority scheduling to prevent new write requests from selecting the storage nodes or disks corresponding to these marked bad shard locations. Simultaneously, new extended shard resources are requested from the management system to replace the extended shards corresponding to the bad shards, restoring the complete redundancy of the storage system.

[0093] If the new extended shard resource is successfully allocated, subsequent writes will be directed to the new extended shard; if the allocation fails temporarily, the remaining degraded extended shards will continue to be used to complete the write, provided that the number of successful shards still meets the minimum threshold, to ensure uninterrupted business continuity.

[0094] It should be noted that, in this section, "degraded extended shards" refers to extended shards whose original extended shards, corresponding to the faulty shards, are still available but are marked as degraded because they are in the degraded redundancy group associated with the faulty shards. These extended shards will continue to be used temporarily to maintain business writes, provided the number of successful shards meets the minimum threshold, rather than using the faulty shards themselves for writes.

[0095] In some embodiments, the data storage method further includes: Receive a read request for the target object and obtain the metadata triplet corresponding to the target object. The metadata triplet includes the extended fragment file identifier, logical offset, and actual length. Based on the extended fragment file identifier, logical offset, and actual length, read all verification information blocks within the target record block from the corresponding extended fragment; Perform integrity verification calculation on the verification data unit of each verification information block, and compare the calculation result with the verification value in the self-description header of the verification information block; If the check values ​​of all check information blocks match, concatenate the check data units of all check information blocks into the target object data and return it. If the verification values ​​of the verification information blocks are inconsistent, the corresponding verification information blocks are marked as abnormal and the background data repair process is triggered.

[0096] In this embodiment, the target object reading process is implemented based on the metadata index of hierarchical structured storage and the block-by-block verification mechanism.

[0097] Upon receiving a read request for the target object, the system retrieves the corresponding metadata triplet. This metadata triplet includes the extended fragment file identifier, logical offset, and actual length. The extended fragment file identifier is a unique identifier for the extended fragment; the logical offset is the starting offset address of the record block corresponding to the target object within the extended fragment; and the actual length is the total length of the original data in that record block. The metadata triplet is generated and stored by the metadata management module after the write operation is complete, providing fast addressing capabilities from the target object name to its physical storage location.

[0098] Based on the extended fragment file identifier, logical offset, and actual length, all checksum blocks within the target record block are read from the corresponding extended fragment. First, the storage node containing the corresponding extended fragment is located using the extended fragment file identifier, and a read request is sent to that node, carrying the logical offset and actual length. After the storage node locates the target record block, all checksum blocks within that record block are read sequentially. The start and end boundaries of the record block are identified through the type flag in the self-description header of the checksum blocks, ensuring that complete record block data is read.

[0099] Integrity check calculations are performed on the check data units of each check information block, and the calculation results are compared with the check value in the self-description header of the check information block. The integrity check calculation algorithm is the same as the cyclic redundancy check algorithm used during writing. Simultaneously, the length field in the header is checked to ensure it matches the actual data length of the check data unit, in order to detect data truncation or loss anomalies.

[0100] If the check values ​​of all check information blocks match and the length verification passes, it indicates that no bit flips or corruption occurred during the storage of all data within the record block. At this point, the check data units of all check information blocks are concatenated into the target object data according to their order within the record block and returned. The concatenation order is determined by the type label and arrangement order of the check information blocks: the first block comes first, followed by the middle blocks, and the last block comes last. Each complete block independently constitutes the entire record block.

[0101] If a discrepancy exists in the checksum comparison of a checksum block, it indicates that the data within that checksum block has been silently corrupted. The storage node marks the corresponding checksum block as abnormal, reports the abnormality to the client, and triggers the background data repair process. The repair method described above utilizes the corresponding location data from other healthy shards under the same stripe to reconstruct the checksum data unit within the abnormal checksum block through erasure coding decoding and writes it back. This repair process is only performed on a single abnormal checksum block and does not affect the reading and return of other normal checksum blocks within the same record block.

[0102] This application also provides a data storage system for distributed object storage, such as... Figure 2As shown, it includes: 01 a management terminal and 02 at least two storage nodes, wherein, The management terminal is configured to generate a shard group to be written, which is generated by erasure coding of the original data of the target object. The shard group to be written includes k data shards and m check shards. Each fragment in the fragment group to be written is written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node. During the writing process, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated. The minimum number threshold is greater than or equal to k and less than or equal to k+m. The extended fragment is internally stored in a hierarchical structure of record blocks and verification information blocks. The storage node is configured to perform a sealing operation on the extended shard after the write operation is completed, using the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncating data in the extended shard that exceeds the boundary, and locking the write permission of the extended shard.

[0103] In summary, the data storage method and system provided in this application solve the problem of slow nodes blocking writes by introducing an early confirmation mechanism with a minimum threshold during the write process, changing the write response latency from being determined by the slowest node to being determined by the minSize-th fastest node. By establishing a global trusted boundary and solidifying the multi-node consistency state through a sealing operation, the data consistency problem that may arise after early confirmation is resolved. Through the design of verification information blocks in the hierarchical structured storage, the granularity of data verification is reduced to the verification information block level, achieving fine-grained silent data corruption detection and accurate reconstruction of abnormal verification information blocks, avoiding full reconstruction of the entire shard or the entire record block. These processes enable a large-scale erasure coding storage system to simultaneously achieve high write availability, data consistency, and operational efficiency in engineering for the first time in a project.

[0104] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data storage method for distributed object storage, characterized in that, include: The original data of the target object is erasure encoded to generate a group of fragments to be written, which contains k data fragments and m parity fragments; Each fragment in the fragment group to be written is written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node, and the extended fragment is stored in a hierarchical structure of record blocks and check information blocks. During the fragment writing process of the fragment group to be written, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated, wherein the minimum number threshold is greater than or equal to k and less than or equal to k+m. Perform a sealing operation on the extended shard after the write operation is completed. Use the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncate the data in the extended shard that exceeds the boundary, and lock the write permissions of the extended shard.

2. The data storage method according to claim 1, characterized in that, The sealing operation is performed on the extended fragment after the write is completed. The sealing operation includes: Determine the logical commit length corresponding to the successfully written extended shard, where the logical commit length is the length of the logical data that has been persisted and confirmed by disk synchronization within the extended shard. The minimum logical commit length of each successfully written extended shard is used as the trusted boundary. Data exceeding the trusted boundary in each extended fragment is truncated; Lock write permissions for each extended shard.

3. The data storage method according to claim 2, characterized in that, The determination of the logical commit length corresponding to the successfully written extended shard includes: Each storage node splits the received fragment into at least one record block, and each record block into at least one verification information block. The record block is a logical write unit within the extended fragment, and each record block uniquely corresponds to a sub-object within the fragment to be written. The verification information block is the smallest storage and verification unit within the record block. Each storage node writes the verification information block of each record block continuously to the corresponding extended fragment according to a preset logical offset; After each storage node completes the physical writing of the verification information block and synchronizes with the disk, it adds the data length of the verification information block written this time to the logical commit length of the corresponding extended shard and reports the synchronization completion status to the client. The logical commit length is the length of the logical data in the extended shard that has completed disk synchronization confirmation and persistence maintained by the storage node side. The client uses the minimum logical commit length of each extended shard in the successfully written extended shard as the trusted boundary, based on the synchronization completion status reported by all storage nodes. Each storage node splits each record block into at least one verification information block, including: Each storage node splits each record block into at least one parity data unit; Each storage node generates a corresponding self-description header for each verification data unit. The self-description header includes: a verification value generated by performing integrity verification calculation on the verification data unit, a length field that records the data length of the verification data unit, and a type flag that identifies the position of the verification information block in its respective record block. Each storage node concatenates each verification data unit with its corresponding self-describing header to generate a corresponding verification information block.

4. The data storage method according to claim 1, characterized in that, Also includes: When an anomaly is detected in the verification information block, the verification data unit in the verification information block is reconstructed by erasure coding using the verification data unit in other healthy segments in the same strip that corresponds to the verification information block, and the reconstructed verification data unit is rewritten into the corresponding extended segment.

5. The data storage method according to claim 1, characterized in that, Before erasure coding is performed on the original data of the target object, the following steps are also included: Determine if the size of the target object is less than a preset small object threshold; If the target object is a small object, the original data of multiple small objects are merged into an aggregated dataset, and the aggregated dataset is used as the original data for performing erasure coding. Assign a unique logical offset within the extended shard to each small object in the aggregated dataset, corresponding to the record block.

6. The data storage method according to claim 1, characterized in that, Before erasure coding is performed on the original data of the target object, the following steps are also included: Determine if the size of the target object is greater than or equal to a preset large object threshold; If the target object is a large object, the original data of the target object will be divided into multiple independent object blocks according to the preset block size; Each object block is assigned a unique object identifier, and each object block is treated as raw data for independent erasure coding.

7. The data storage method according to claim 1, characterized in that, Also includes: When there are shards that have not returned write results, continuously monitor the response status of those shards. If the shard to be written returns a write failure response or no response within the preset return time threshold, the shard to be written is marked as a bad shard, and update information is sent to the metadata management module.

8. The data storage method according to claim 7, characterized in that, After marking the fragment to be written as a bad fragment, the following is also included: In subsequent write scheduling, the positions of fragments marked as bad fragments will be excluded from the priority scheduling range; Request new extended shard resources from the management console to replace the extended shard corresponding to the bad shard.

9. The data storage method according to claim 1, characterized in that, Also includes: Receive a read request for the target object and obtain the metadata triplet corresponding to the target object. The metadata triplet includes the extended fragment file identifier, logical offset, and actual length. Based on the extended fragment file identifier, logical offset, and actual length, read all verification information blocks within the target record block from the corresponding extended fragment; Perform integrity verification calculation on the verification data unit of each verification information block, and compare the calculation result with the verification value in the self-description header of the verification information block; If the check values ​​of all check information blocks match, concatenate the check data units of all check information blocks into the target object data and return it. If the verification values ​​of the verification information blocks are inconsistent, the corresponding verification information blocks are marked as abnormal and the background data repair process is triggered.

10. A data storage system for distributed object storage, characterized in that, Includes a management console and at least two storage nodes, among which, The management terminal is configured to generate a shard group to be written, which is generated by erasure coding of the original data of the target object. The shard group to be written includes k data shards and m check shards. Each fragment in the fragment group to be written is written to an extended fragment distributed on different storage nodes. The extended fragment is an independent physical file on the disk of the storage node. During the writing process, when the number of fragments confirmed to have been successfully written reaches a preset minimum number threshold, a response indicating that the target object has been successfully written is generated. The minimum number threshold is greater than or equal to k and less than or equal to k+m. The extended fragment is internally stored in a hierarchical structure of record blocks and verification information blocks. The storage node is configured to perform a sealing operation on the extended shard after the write operation is completed, using the minimum logical commit length corresponding to all successfully written shards as the trusted boundary, truncating data in the extended shard that exceeds the boundary, and locking the write permission of the extended shard.

Images