Data layout method for completing disk write-in through one-time IO

Abstract

The invention discloses a data layout method for completing disk write-in through one-time IO, belongs to the technical field of data layout of disk data storage, and aims to solve the technical problem that disk I / O operation is performed for multiple times in a traditional disk I / O process. According to the technical scheme, the method comprises the steps that a bare disk of a management disk is designed and arranged, wherein a physical disk is divided into five partitions including a Super Block, a Block partition table, a Chunk table, a metadata reservation area and a Data area; the data structure is used for storing metadata by utilizing an adjacency table in the graph data structure, and realizing rapid positioning and reconstruction through an index and a hash table, so that data on a disk is effectively managed and distributed; data layout organization and data integrity: ensuring data integrity through layout design organization of a sector of each piece of data; and data reading and writing: performing a reading and writing process of the used disk data layout.

Description

Technical Field

[0001] The present invention relates to the technical field of data layout of disk data storage, in particular to a data layout method for completing disk writing in one IO operation. Background Art

[0002] In the storage field, when writing data to disk, first, the data itself is written to the disk, and then in a separate step, the related metadata, such as data location, checksum, etc., are written to the disk. Each step in this process requires disk I / O operations, which may increase the overall write latency and increase system complexity and resource consumption.

[0003] The traditional disk I / O process usually includes the following steps:

[0004] (1) Request initiation: When an application needs to read or write data on the disk, it sends a request to the operating system.

[0005] (2) Request queuing: If there are multiple I / O requests waiting to be processed, they may be queued for execution. This is usually done in the I / O scheduler of the operating system.

[0006] (3) Disk addressing: Once a request is scheduled for execution, the disk drive needs to locate the disk track and sector where the data is located. This process involves the movement of the head and the rotation of the disk, which is usually called addressing delay.

[0007] (4) Data transfer: Once the data location is determined, the data is read or written to the disk.

[0008] (5) Confirmation and return: Once the data transfer is completed, the disk will return a confirmation message and the result of the request to the operating system.

[0009] In the traditional data writing process, two or more disk I / O operations are usually required. First, the data itself is written to the disk, and then the related metadata (such as data location, checksum, etc.) is written. These two steps may cause additional addressing delay and data transmission time, thereby increasing the overall write latency. Summary of the invention

[0010] The technical task of the present invention is to provide a data layout method that completes disk writing in one IO to solve the problem of multiple disk I / O operations in the traditional disk I / O process.

[0011] The technical task of the present invention is achieved in the following way: a data layout method for completing disk writing in one IO, the method is as follows:

[0012] Manage the bare disk design layout of the disk: divide a physical disk into five partitions: Super Block, Block partition table (BAT), Chunk table, metadata reserved area and Data area. The Super Block is located at the front of the disk and is the global table of the disk. It records the global information of the disk, similar to the super block in the file system. The Block partition table is similar to Microsoft's FAT (File Allocation Table), which records the allocation information of each block on the disk. The Chunk table records all Chunk meta information and adopts a lazy update method, that is, the chunk meta information is not updated immediately each time it is written. Only when the update of any sector area exceeds the set threshold, the meta information is written to the disk. The metadata reserved area is filled with 0 and is reserved for future metadata design modifications. The Data area stores the actual block data. Each block contains only data without additional metadata information.

[0013] Data structure: Use the adjacency list in the graph data structure to store metadata, and use indexes and hash tables to quickly locate and rebuild, thereby effectively managing and distributing data on disk;

[0014] Data layout organization and data integrity: Ensure data integrity by organizing the layout design of each data sector;

[0015] Data reading and writing: The reading and writing process of the disk data layout used.

[0016] As a preference, the Super Block parameters are as follows:

[0017] Disk UUID: used to uniquely identify the disk;

[0018] Disk number: the number of the disk in the system;

[0019] Hardware model and parameter settings: record the hardware model and related parameter settings of the disk;

[0020] Manufacturer-specific parameter settings: including special parameters customized by disk manufacturers;

[0021] Maximum number of allocatable blocks: calculated based on the disk size and block size;

[0022] The maximum number of allocatable chunks: calculated based on the disk size and block size, assuming that one chunk occupies one block;

[0023] Global information recording: record the number of bytes written, daily write limit (dwpd) and number of bad blocks;

[0024] Whether it is formatted: record whether the disk is formatted;

[0025] Sector number: records the total number of sectors on the disk;

[0026] Epoch: Power-off related settings;

[0027] Trim related: record whether the TRIM command is supported and related settings;

[0028] Its own CRC information: used to verify the integrity of the Super Block data.

[0029] As a preferred option, each block in the Block partition table occupies 4B of records for storing the next LBA (Logical Block Address) number, which means 4K*4G=16TB of space. If the capacity of SSD exceeds 16TB in the future, this may cause problems.

[0030] In order to ensure the reliability of metadata, a 4-byte CRC (cyclic redundancy check) is required for each sector and placed at the end of each 4KB.

[0031] If the next LBA number is 0, it means that the corresponding block has ended; if the next LBA number is not 0, it means there is a next block; among them, the corresponding LBA 0 has been used by the Super Block and will not be allocated to the Data area.

[0032] Preferably, each chunk meta in the Chunk table occupies 40B of space, which includes chunk ID (16B), block creation time (4B), flag (currently only marks whether to delete, 2B), number of blocks occupied by the chunk (4B), and LBA information of the first block (4B);

[0033] An additional 10B expansion is added to ensure scalability;

[0034] Each sector 4096B stores 102 40B chunk meta information, and the last 16B is used to record CRC.

[0035] As a preferred embodiment, the data structure is as follows:

[0036] Block partition table indexes to block location: The Block partition table (BAT, Block Allocation Table) directly indexes to the location of the block, thereby determining the location of the block on the disk;

[0037] The Chunk table records the deletion mark: if the chunk meta information is deleted, the chunk meta information is placed in the Free List; if the chunk meta information is not allocated, the chunk meta information is also added to the Free List; a hash table is added to the index structure of the Chunk table to quickly locate the chunk meta information; the hash table is loaded from the memory when the system starts and is quickly rebuilt when needed;

[0038] In the block list allocation diagram, Id1 points to the information of Meta1. The last block contains the block address of the first LBA, for example, 26. Then, starting from the block address of the first LBA contained in the last block, a query is performed in the Block partition table to obtain a block chain, namely 26->1->17->28->0, which means that chunk id1 contains a total of 4 blocks.

[0039] As a preference, each data sector has a header describing the status, which can be divided into the following situations:

[0040] Scenario 1:

[0041] Completely write the data Data. If prev_size does not exist, set prev_size to 0;

[0042] The user can only write once in the sector, and the final padding is optional. If it is not present, it means that the corresponding sector is full.

[0043] At this time, curr_size=4072, otherwise curr_size is any value within (0, 4072), and the data up to curr_size is complete;

[0044] Scenario 2:

[0045] When multiple data are written in a sector, prev_size is set to the value of the previous write, and curr_size is set to the value of the latest write;

[0046] If the sector is full, curr_size = 4072;

[0047] The data written by the user is written once and completely, without tracing back to the previous sector; the length of the data written by the user is curr_size-prev_size;

[0048] Once a write occurs again, prev_size is assigned to curr_size, and curr_size is assigned to the new size;

[0049] Scenario 3: Cross-sector scenario:

[0050] If the curr_size of the previous sector is 4072 and the prev_size of the sector is 0, the data of the corresponding sector belongs to the same complete write by the user;

[0051] If the data of the following sector is damaged, the data of the previous sector will also be unavailable;

[0052] If the prev_size of the previous sector is 0, continue to trace back until the prev_size of any sector is 0 or the first sector, ensuring that the user's integrity write can be traced;

[0053] If a sector is fully written and there is no subsequent sector, it is impossible to determine whether there will be new data during replay. It is necessary to maintain a flag in sector_flags, namely the has_next state, to indicate whether the corresponding data has a nextsector.

[0054] As a preferred method, data reading and writing are as follows:

[0055] First write;

[0056] Not the first write;

[0057] Read.

[0058] Preferably, the first write is:

[0059] Check whether the chunk exists: Check whether the chunk meta information already exists in the hash table;

[0060] Get the available block partition table: If it is the first time to write chunk meta information, get the available LBA from the free list;

[0061] Write LBA information on the Block partition table: Write 0 at the LBA on the Block partition table, indicating that there is no next block;

[0062] Write user data: write user data at the specified LBA;

[0063] Persistent metadata information.

[0064] More preferably, the non-first write is specifically:

[0065] Query the current write location of the Chunk table: query the current write location of the chunk meta information from the hash table;

[0066] Get available blocks: If you need to switch blocks, get available blocks from the free list;

[0067] Update the Block partition table information: write the LBA of the last block to the new nextLBA in the Block partition table;

[0068] Write data: write user data at the specified LBA location;

[0069] Each 1MB switched requires an additional IO.

[0070] Preferably, the reading is as follows:

[0071] Query the specified read position of the chunk: query the specified read position of the chunk from the hash table;

[0072] Since the Chunk table only records the location of the first LBA, it is necessary to chain search for subsequent locations or use a cached handle data structure to avoid chain search.

[0073] The data layout method of the present invention that completes disk writing in one IO has the following advantages:

[0074] (I) The present invention can cleverly write data and its metadata to the disk through a single I / O operation, thereby significantly improving the read and write performance under the same disk hardware conditions, so that the storage system using the technology of the present invention has excellent performance, including latency, IOPS and throughput. The present invention has a certain degree of universality, and any server computer using disk storage on the Linux operating system and any system that needs to design data layout on the disk;

[0075] (ii) The present invention reduces access delay: Under the premise of ensuring that data is correctly written to the disk, by reducing the number of I / O disk operations, it is obvious that the access delay of the storage system to the disk can be reduced. Completing data writing at one time can avoid the waiting time of multiple disk operations, thereby greatly improving the efficiency of data writing;

[0076] (III) The present invention reduces system overhead: the disk I / O process will generate system calls, which will introduce certain overhead. In particular, by reducing the number of disk operations of I / O in the case of high concurrency, not only the access delay is reduced, but also the overhead caused by system calls is reduced, thereby improving the efficiency and throughput of the system. This is particularly important in the case of high concurrency, as it can improve the efficiency and throughput of the system and reduce the burden on the system.

[0077] (IV) The present invention improves application performance: by reducing the number of I / O disk operations, in particular, the number of accesses to slow storage media can be reduced, thereby speeding up data reading; this is particularly important for applications that need to read data frequently, and can significantly improve their performance;

[0078] (V) The present invention reduces system load: by reducing the number of I / O disk operations, the kernel load can be reduced, the system's concurrency and stability can be improved, and the system can maintain high performance under high load conditions;

[0079] (VI) The present invention improves disk utilization: through the ingenious design of data layout and efficient data structure, a more compact and reasonable disk organization structure means that more data can be stored in a limited space, thereby improving disk utilization;

[0080] (VII) The purpose of the present invention is to reduce the number of disk I / Os, improve the efficiency of data access and system performance, and reduce access latency through data layout design, thereby meeting the performance requirements in different application scenarios;

[0081] (VIII) prev_crc and curr_crc in the data format of the present invention are used to verify data integrity, and data damage can be detected;

[0082] (IX) The present invention can be traced back to a complete write, ensuring that neither partial write nor error occurs in the data;

[0083] (J) Each time the present invention writes, the update of prev_size and curr_size and the maintenance of sector_flags ensure the integrity and traceability of the data;

[0084] (XI) The present invention can achieve the purpose of not having to persist the length of a chunk each time, because the unwritten data is checked by CRC, thereby ensuring the integrity of the data; specifically, the first layer does not record the data length at the bare disk level, and the second layer uses the data storage Layout to obtain the actual data length, while solving the data integrity problem, that is, completing the write operation through one IO, thereby improving the write efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] The present invention is further described below in conjunction with the accompanying drawings.

[0086] Attached Figure 1 Design a layout diagram for managing raw disks;

[0087] Attached Figure 2 It is a schematic diagram of the block linked list allocation diagram;

[0088] Attached Figure 3 Describe the status diagram for the sector's Header;

[0089] Attached Figure 4 This is a schematic diagram of the second state description for the sector header;

[0090] Attached Figure 5 This is a schematic diagram of the cross-sector situation. DETAILED DESCRIPTION

[0091] A data layout method for completing disk writing in one IO according to the present invention is described in detail below with reference to the accompanying drawings and specific embodiments of the specification.

[0092] Example:

[0093] This embodiment provides a data layout method for completing disk writing in one IO, and the method is specifically as follows:

[0094] S1. Management disk bare disk design layout: as shown in the attached Figure 1 As shown in the figure, a physical disk is divided into five partitions: Super Block, Block partition table (BAT), Chunk table, metadata reserved area and Data area. Among them, SuperBlock is located at the front of the disk and is the global table of the disk. It records the global information of the disk, similar to the super block in the file system. The Block partition table is similar to Microsoft's FAT (File Allocation Table), which records the allocation information of each block on the disk. The Chunk table records all Chunk meta information and adopts lazy update mode, that is, the chunk meta information is not updated immediately each time it is written. Only when the update of any sector area exceeds the set threshold, the meta information is written to the disk. The metadata reserved area is filled with 0 and is reserved for future metadata design modifications. Without migrating data, only the previous metadata information can be converted offline. The Data area stores the actual block data. Each block contains only data without additional metadata information.

[0095] S2. Data structure: Use the adjacency list in the graph data structure to store metadata, and use indexes and hash tables to quickly locate and rebuild, so as to effectively manage and distribute data on the disk;

[0096] S3, data layout organization and data integrity: ensure data integrity by organizing the layout design of each data sector;

[0097] S4, data reading and writing: the reading and writing process of the disk data layout used.

[0098] The Super Block parameters in this embodiment are as follows:

[0099] Disk UUID: used to uniquely identify the disk;

[0100] Disk number: the number of the disk in the system;

[0101] Hardware model and parameter settings: record the hardware model and related parameter settings of the disk;

[0102] Manufacturer-specific parameter settings: including special parameters customized by disk manufacturers;

[0103] Maximum number of allocatable blocks: calculated based on the disk size and block size;

[0104] The maximum number of allocatable chunks: calculated based on the disk size and block size, assuming that one chunk occupies one block;

[0105] Global information recording: record the number of bytes written, daily write limit (dwpd) and number of bad blocks;

[0106] Whether it is formatted: record whether the disk is formatted;

[0107] Sector number: records the total number of sectors on the disk;

[0108] Epoch: Power-off related settings;

[0109] Trim related: record whether the TRIM command is supported and related settings;

[0110] Its own CRC information: used to verify the integrity of the Super Block data.

[0111] In the block partition table of this embodiment, each block allocated record occupies 4B, which is used to store the next LBA (logical block address) number, indicating 4K*4G=16TB of space. If the capacity of the SSD exceeds 16TB in the future, it may cause problems.

[0112] In order to ensure the reliability of metadata, a 4-byte CRC (cyclic redundancy check) is required for each sector and placed at the end of each 4KB.

[0113] If the next LBA number is 0, it means that the corresponding block has ended; if the next LBA number is not 0, it means there is a next block; among them, the corresponding LBA 0 has been used by the Super Block and will not be allocated to the Data area.

[0114] In the Chunk table of this embodiment, each chunk meta occupies 40B of space, which includes chunkID (16B), block creation time (4B), flag (currently only marks whether to delete, 2B), number of blocks occupied by the chunk (4B), and LBA information of the first block (4B);

[0115] An additional 10B expansion is added to ensure scalability;

[0116] Each sector 4096B stores 102 40B chunk meta information, and the last 16B is used to record CRC.

[0117] The data structure in step S2 of this embodiment is as follows:

[0118] S1. Block partition table indexes to block location: The Block partition table (BAT, Block Allocation Table) directly indexes to the location of the block, thereby determining the location of the block on the disk;

[0119] S2. Chunk table record deletion mark: if the chunk meta information is deleted, the chunk meta information is placed in the Free List; if the chunk meta information is not allocated, the chunk meta information is also added to the Free List; a hash table is added to the index structure of the Chunk table to quickly locate the chunk meta information; the hash table is loaded from the memory when the system starts and is quickly rebuilt when needed;

[0120] S3, block list allocation diagram, as shown in the attached Figure 2 As shown, Id1 points to the information of Meta1. The last block contains the block address of the first LBA, for example, 26. Then, starting from 26, the query in the Block partition table obtains a blockchain, namely 26->1->17->28->0, which means that chunk id1 contains a total of 4 blocks.

[0121] As attached Figure 3 As shown, in this embodiment, each data sector has a header describing the status, which is divided into the following situations:

[0122] Scenario 1:

[0123] Completely write the data Data. If prev_size does not exist, set prev_size to 0;

[0124] The user can only write once in the sector, and the final padding is optional. If it is not present, it means that the corresponding sector is full.

[0125] At this time, curr_size=4072, otherwise curr_size is any value within (0, 4072), and the data up to curr_size is complete;

[0126] As attached Figure 4 As shown, situation two:

[0127] When multiple data are written in a sector, prev_size is set to the value of the previous write, and curr_size is set to the value of the latest write;

[0128] If the sector is full, curr_size = 4072;

[0129] The data written by the user is written once and completely, without tracing back to the previous sector; the length of the data written by the user is curr_size-prev_size;

[0130] Once a write occurs again, prev_size is assigned to curr_size, and curr_size is assigned to the new size;

[0131] As attached Figure 5 As shown, scenario 3: cross-sector scenario:

[0132] If the curr_size of the previous sector is 4072 and the prev_size of the sector is 0, the data of the corresponding sector belongs to the same complete write by the user;

[0133] If the data of the following sector is damaged, the data of the previous sector will also be unavailable;

[0134] If the prev_size of the previous sector is 0, continue to trace back until the prev_size of any sector is 0 or the first sector, ensuring that the user's integrity write can be traced;

[0135] If a sector is fully written and there is no subsequent sector, it is impossible to determine whether there will be new data during replay. It is necessary to maintain a flag in sector_flags, namely the has_next state, to indicate whether the corresponding data has a nextsector.

[0136] Summarize:

[0137] -The prev_crc and curr_crc in the data format are used to verify data integrity, and data corruption can be detected.

[0138] -Through the above algorithm, a complete write can be traced back, ensuring that the data will neither be partially written nor wrong.

[0139] - At each write, the updating of prev_size and curr_size and the maintenance of sector_flags ensure the integrity and traceability of the data.

[0140] Through the above mechanism, the purpose of not needing to persist the length of the chunk every time can be achieved. This is because the unwritten data is checked by CRC, thus ensuring the integrity of the data.

[0141] Specifically, the first layer does not record the data length at the raw disk level, while the second layer uses the data storage layout to obtain the real data length, while solving the data integrity problem. That is, the write operation is completed through one IO, thereby improving the write efficiency.

[0142] The data reading and writing in step S4 of this embodiment are specifically as follows:

[0143] S401, first writing;

[0144] S402, non-first writing;

[0145] S403: Read.

[0146] The first writing in step S401 of this embodiment is specifically as follows:

[0147] S40101. Check whether the chunk exists: Check whether the chunk meta information exists in the hash table.

[0148] S40102. Get available block partition table: If it is the first time to write chunk meta information, get available LBA from freelist;

[0149] S40103. Write LBA information in the Block partition table: Write 0 at the LBA in the Block partition table, indicating that there is no next block;

[0150] S40104, write user data: write user data at the specified LBA;

[0151] S40105. Persistent metadata information.

[0152] The non-first writing in step S402 of this embodiment is specifically as follows:

[0153] S40201. Query the location where the Chunk table is currently written: query the location where the chunk meta information is currently written from the hash table;

[0154] S40202, obtain available blocks: if you need to switch blocks, obtain available blocks from the free list;

[0155] S40203, update the Block partition table information: write the LBA of the last block to the new next LBA in the Block partition table;

[0156] S40204, write data: write user data at the specified LBA location;

[0157] S40205. Each 1MB switch requires an additional IO.

[0158] The reading in step S403 of this embodiment is specifically as follows:

[0159] S40301. Query the specified read position of the Chunk: Query the specified read position of the Chunk from the hash table;

[0160] S40302. Since the Chunk table only records the location of the first LBA, it is necessary to chain search for subsequent locations or use a cached handle data structure to avoid chain search.

[0161] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data layout method for completing disk writing in one IO, characterized in that: The method is as follows: Manage the bare disk design layout of the disk: divide a physical disk into five partitions: Super Block, Block partition table, Chunk table, metadata reserved area and Data area. The Super Block is located at the front of the disk and is the global table of the disk, recording the global information of the disk. The Block partition table records the allocation information of each block on the disk. The Chunk table records all Chunk meta information and adopts lazy update mode, that is, the chunk meta information is not updated immediately each time it is written. The metadata reserved area is filled with 0 and reserved for future metadata design modifications. The Data area stores the actual block data. Each block contains only data without additional metadata information. Data structure: Use the adjacency list in the graph data structure to store metadata, and use indexes and hash tables to quickly locate and rebuild, thereby effectively managing and distributing data on disk; Data layout organization and data integrity: Ensure data integrity by organizing the layout design of each data sector; Data reading and writing: The reading and writing process of the disk data layout used.

2. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: The SuperBlock parameters are as follows: Disk UUID: used to uniquely identify the disk; Disk number: the number of the disk in the system; Hardware model and parameter settings: record the hardware model and related parameter settings of the disk; Manufacturer-specific parameter settings: including special parameters customized by disk manufacturers; Maximum number of allocatable blocks: calculated based on the disk size and block size; The maximum number of allocatable chunks: calculated based on the disk size and block size, assuming that one chunk occupies one block; Global information recording: record the number of bytes written, daily write limit and number of bad blocks; Whether it is formatted: record whether the disk is formatted; Sector number: records the total number of sectors on the disk; Epoch: Power-off related settings; Trim related: record whether the TRIM command is supported and related settings; Its own CRC information: used to verify the integrity of the Super Block data.

3. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: Each block in the block partition table occupies 4 bytes and is used to store the next LBA sequence number. A 4B CRC needs to be located for each sector and placed at the end of each 4KB. If the next LBA number is 0, it means that the corresponding block has ended; if the next LBA number is not 0, it means there is a next block; among them, the corresponding LBA 0 has been used by the Super Block and will not be allocated to the Data area.

4. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: Each chunk meta in the chunk table occupies 40B of space, which includes the chunk ID, block creation time, flag, number of blocks occupied by the chunk, and LBA information of the first block; An additional 10B expansion is added to ensure scalability; Each sector 4096B stores 102 40B chunk meta information, and the last 16B is used to record CRC.

5. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: The data structure is as follows: Block partition table indexes to block location: The block partition table directly indexes to the location of the block, thereby determining the location of the block on the disk; The Chunk table records the deletion mark: if the chunk meta information is deleted, the chunk meta information is placed in the Free List; if the chunk meta information is not allocated, the chunk meta information is also added to the Free List; a hash table is added to the index structure of the Chunk table to quickly locate the chunk meta information; the hash table is loaded from the memory when the system starts and is quickly rebuilt when needed; In the block chain allocation diagram, Id1 points to the information of Meta1, and the last block contains the block address of the first LBA. Then, starting from the block address of the first LBA contained in the last block, the query is performed in the Block partition table to obtain a block chain.

6. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: Each data sector has a header describing the status, which can be divided into the following situations: Scenario 1: Completely write the data Data. If prev_size does not exist, set prev_size to 0; The user can only write once in the sector, and the final padding is optional. If it is not present, it means that the corresponding sector is full. At this time, curr_size=4072, otherwise curr_size is any value within (0, 4072), and the data up to curr_size is complete; Scenario 2: When multiple data are written in a sector, prev_size is set to the value of the previous write, and curr_size is set to the value of the latest write; If the sector is full, curr_size = 4072; The data written by the user is written once and completely, without tracing back to the previous sector; the length of the data written by the user is curr_size-prev_size; Once a write occurs again, prev_size is assigned to curr_size, and curr_size is assigned to the new size; Scenario 3: Cross-sector scenario: If the curr_size of the previous sector is 4072 and the prev_size of the sector is 0, the data of the corresponding sector belongs to the same complete write by the user; If the data of the following sector is damaged, the data of the previous sector will also be unavailable; If the prev_size of the previous sector is 0, continue to trace back until the prev_size of any sector is 0 or the first sector, ensuring that the user's integrity write can be traced; If a sector is fully written and there is no subsequent sector, it is impossible to determine whether there will be new data during replay; It is necessary to maintain a flag in sector_flags, namely the has_next state, to indicate whether the corresponding data has a nextsector.

7. The data layout method for completing disk writing in one IO according to claim 1, characterized in that: The data reading and writing are as follows: First write; Not the first write; Read.

8. The data layout method for completing disk writing in one IO according to claim 7, characterized in that: The first write is as follows: Check whether the chunk exists: Check whether the chunk meta information already exists in the hash table; Get the available block partition table: If it is the first time to write chunk meta information, get the available LBA from the free list; Write LBA information on the Block partition table: Write 0 at the LBA on the Block partition table, indicating that there is no next block; Write user data: write user data at the specified LBA; Persistent metadata information.

9. The data layout method for completing disk writing in one IO according to claim 7, characterized in that: The non-first write is specifically: Query the current write location of the Chunk table: query the current write location of the chunk meta information from the hash table; Get available blocks: If you need to switch blocks, get available blocks from the freelist; Update the Block partition table information: write the LBA of the last block to the new next LBA in the Block partition table; Write data: write user data at the specified LBA location; Each 1MB switched requires an additional IO.

10. The data layout method for completing disk writing in one IO according to claim 7, characterized in that: Read as follows: Query the specified read position of the chunk: query the specified read position of the chunk from the hash table; Chain search for subsequent locations or use a cached handle data structure to avoid chain search.

Images