Storage system

Abstract

This streamlines the writing of data assurance codes. [Solution] The storage system includes a processor and memory, and is capable of performing atomic writes to guarantee the data before the update during data update writing. The processor determines whether to apply the atomic write based on the write parameters of the data guarantee code of the user data to be updated. If it determines to apply the atomic write, it performs an update write of the data guarantee code using the atomic write. If it determines not to apply the atomic write, it writes log data including a copy of the data guarantee code, and then writes the data guarantee code.

Description

Technical Field

[0001] The present invention relates to a storage system.

Background Art

[0002] As the background art of the present disclosure, there is Japanese Patent Application Laid-Open No. 2023-40672. Japanese Patent Application Laid-Open No. 2023-40672 discloses a storage system that suppresses writing to a storage device in additional processing for solving the light hole problem.

[0003] The storage system includes a computer, a non-volatile storage device, and a high-speed storage device that can be accessed faster than the storage device. A drive log including write log information is recorded in the high-speed storage device. When the computer receives a write request for write data, it first performs a drive log check process and then a data write process. In the drive log check process, when a duplicate write log record is recorded in the drive log, the write log state of the duplicate write log record is changed to "completed" for the drive log and the write log information, and then the process proceeds to the data write process. When it is not recorded, the process proceeds to the data write process without changing the drive log and the write log information (see, for example, the summary).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Some storage systems generate data assurance codes from user data and store these codes in a separate physical storage area. These data assurance codes can improve reliability. From the perspective of improving storage system performance, it is desirable to make the writing of data assurance codes to physical storage more efficient. [Means for solving the problem]

[0006] The storage system includes a processor and memory, and is capable of performing atomic writes to guarantee the data before the update during data update writing. The processor determines whether to apply the atomic write based on the write parameters of the data guarantee code of the user data to be updated. If it determines to apply the atomic write, it performs an update write of the data guarantee code using the atomic write. If it determines not to apply the atomic write, it writes log data including a copy of the data guarantee code, and then writes the data guarantee code. [Effects of the Invention]

[0007] One embodiment of the present invention improves the performance of a storage system. [Brief explanation of the drawing]

[0008] [Figure 1] An example of the storage system configuration according to Example 1 is shown. [Figure 2] An example of a storage node hardware configuration is shown. [Figure 3] This figure shows an example of the logical configuration of a storage node. [Figure 4] This section describes an example of data protection in a storage system. [Figure 5] This diagram schematically shows the configuration of the storage area of ​​a storage device or cloud block storage service. [Figure 6] This diagram illustrates the write processing flow of the log-write method. [Figure 7] This diagram illustrates the light processing flow using the atomic light function. [Figure 8A] This diagram illustrates the selection of the atomic light method. [Figure 8B] This diagram illustrates the selection of the log-write method. [Figure 9] An example of a volume area management table configuration is shown. [Figure 10] This shows an example of the configuration of a storage device area management table. [Figure 11] This shows an example configuration for Atomic Light Requirements Management Table 0. [Figure 12] An example flowchart for write operations in a storage system is shown. [Figure 13] Figure 12 shows an example flowchart of the destaging process. [Figure 14] Figure 13 shows an example flowchart of the DIF drive storage process. [Figure 15] An example flowchart of the destaging process in Example 2 is shown. [Figure 16] Figure 15 shows an example flowchart of the DIF drive storage process on the standby node. [Modes for carrying out the invention]

[0009] The embodiments of the present invention will be described below with reference to the drawings. However, the present invention is not to be construed as being limited to the embodiments described below. It will be readily apparent to those skilled in the art that the specific configuration can be modified without departing from the spirit or intent of the present invention.

[0010] In this specification, the designations "First," "Second," "Third," etc., are used to identify components and do not necessarily limit their number or order. In the configuration of the invention described below, identical or similar components or functions are denoted by the same reference numerals, and redundant descriptions are omitted.

[0011] In the following description, when describing elements of the same type without distinction, common reference signs (or reference signs) in the reference signs are used. When describing elements of the same type separately, reference signs (or element IDs) may be used.

[0012] The program is executed by a processor (e.g., a CPU (Central Processing Unit)) included in a storage controller in a storage device, and thus performs defined processes while appropriately using storage resources (e.g., a memory) and / or a communication interface device (e.g., a host I / F). Therefore, the subject of the process may be the storage device or the processor. Further, the storage controller may include a hardware circuit that performs part or all of the processes. The computer program may be installed from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium.

Example

[0013] FIG. 1 shows a configuration example of a storage system according to Example 1. The storage system 100 includes a plurality of storage nodes 103. The storage system 100 is scalable and allows addition and deletion of the storage nodes 103. The storage system 100 is, for example, SDS (Software Defined Storage). The storage system 100 may further include a management node. The host device accesses the storage system 100 to write and read data.

[0014] The storage nodes 103 are interconnected via a network 102 composed of a Fibre Channel, Ethernet, a LAN (Local Area Network), or the like.

[0015] The storage node 103 is a computer device that includes one or more physical storage devices (also called storage drives or simply drives) 133 and provides storage space to the host device for reading and writing data. The storage node 103 is, for example, a general-purpose server device.

[0016] Storage node 103 runs cloud compute service 131 and cloud block storage service 132. Cloud compute service 131 transfers user data between the host device and cloud block storage service 132. Cloud compute service 131 receives data from the host device, performs predetermined processing on it, and transfers it to cloud block storage service 132. It also performs predetermined processing on data received from cloud block storage service 132 and transfers it to the host device.

[0017] The cloud block storage service 132 stores various data, including user data, in one or more physical storage devices 133 and reads that data from the storage devices 133. For example, the cloud block storage service 132 provides a single storage area managed by an LBA (Logival Block Address) and provides a so-called atomic write function as a platform function.

[0018] The atomic write function guarantees the atomicity of writing an entire block; that is, it guarantees that either all the data in a block has been written, or that no data has been written at all. In this way, the atomic write function guarantees that even if a shorn write occurs during the writing process, the data state will remain either "before writing" or "after writing." This function eliminates the need to rewrite data, thereby improving the performance of the storage system. The atomic write feature can improve performance by eliminating the need to rewrite metadata twice.

[0019] Thus, the storage system 100 can include two or more storage nodes 103. The illustrated configuration is illustrative; the host device, storage node 103, and management node may be the same node, implemented as virtual machines or containers, or coexist as processes. The number of storage nodes may be just one.

[0020] Figure 2 shows an example of the hardware configuration of storage node 103. Storage node 103 includes a CPU 135, memory 136, multiple storage devices 133 (Drives), and a communication device 134 (NIC).

[0021] The CPU 135 is the processor that controls the operation of the entire storage node. Memory 136 is used to temporarily hold various programs and necessary data. The CPU 135 executes the programs stored in volatile memory 136, thereby executing various processes for the entire storage node 103 as described later.

[0022] The storage device 133 includes one or more types of high-capacity non-volatile storage devices, such as an SSD (Solid State Drive). The storage device 133 provides a physical storage area for reading or writing data in response to I / O requests from the host device.

[0023] The communication device 134 is an interface for the storage node 103 to communicate with the host device, other storage nodes 103, or the management node via the network 102. The communication device 134 is composed of, for example, a NIC, an FC card, etc. The communication device 134 performs protocol control when communicating with the host device, other storage nodes 103, or the management node.

[0024] Figure 3 shows an example of the logical configuration of a storage node 103. The storage node 103 has memory 136. Memory 136 stores multiple programs, which include a front-end driver 181, a back-end driver 187, one or more storage controllers 183, and a data protection control unit 186. Figure 3 illustrates two storage controllers 183 in each node 103.

[0025] The front-end driver 181 is software that controls the communication device 134 and provides the storage controller 183 with an abstract interface for communication with the host device, other storage nodes 103, or management nodes.

[0026] The backend driver 187 is software that controls each storage device 133 within its own storage node 103 and provides an abstract interface for communication with each storage device 133.

[0027] The storage controller 183 is software that functions as a controller for SDS (Software Defined Storage). The storage controller 183 receives I / O requests from the host device and issues I / O commands corresponding to those requests to the data protection control unit 186.

[0028] Furthermore, the storage controller 183 has a logical volume configuration function. The logical volume configuration function associates the logical chunks configured by the data protection control unit 186 with the logical volumes to be provided to the host. For example, a straight mapping method (where logical chunks and logical volumes are associated one-to-one, and the addresses of the logical chunks and logical volumes are the same) may be used. Alternatively, a virtual volume function (thin provisioning) method (where logical volumes and logical chunks are divided into small-sized areas (pages), and the addresses of logical volumes and logical chunks are associated on a page-by-page basis) may be adopted.

[0029] Each storage controller 183 implemented on storage node 103 is managed as a pair that forms a redundant configuration with other storage controllers 183 located on other storage nodes 103. Hereafter, this pair will be referred to as storage controller group 185.

[0030] Note that Figure 3 shows a case where two storage controllers 183 constitute one storage controller group 185. A redundant configuration may be configured with three or more storage controllers 183. For example, one storage controller may be in active mode while the others are in standby mode.

[0031] In the storage controller group 185, one storage controller 183 is configured to accept I / O requests from the host device (this is the active system state, hereinafter referred to as active mode). The other storage controller 183 in the same storage controller group 185 is configured to not accept I / O requests from the host device (this is the standby system state, hereinafter referred to as standby mode). The node in active mode is called the active node, and the node in standby mode is called the standby node.

[0032] In storage controller group 185, if a failure occurs in storage controller 183 (hereinafter referred to as the active storage controller) which is set to active mode, or in storage node 103 where the active storage controller is located, the state of storage controller 183 (hereinafter referred to as the standby storage controller) which was previously set to standby mode is switched to active mode.

[0033] This allows the standby storage controller to take over the I / O processing that the active storage controller was performing if the active storage controller becomes inoperable. To achieve this function, the standby storage node controller maintains redundant user data caches and control information from the active storage node controller.

[0034] The data protection control unit 186 is software that allocates physical storage space provided by storage devices 133 within its own storage node 103 or other storage nodes 103 to each storage controller group 185, and has the function of reading or writing specified data to the corresponding storage device 133 in accordance with I / O commands provided by the storage controller 183.

[0035] When the data protection control unit 186 allocates physical storage space provided by a storage device 133 in another storage node 103 to the storage controller group 185, it cooperates with the data protection control unit 186 implemented in that other storage node 103 to read or write data to the storage space in accordance with the I / O commands given by the storage controller of the storage controller group 185 by exchanging data with that data protection control unit 186 via the network 102.

[0036] When the data protection control unit 186 receives an I / O command, it exchanges data with other data protection control units 186 in other storage nodes 103 via the network 102 and stores redundant data within the storage system 100. This prevents data loss in the event of a failure of a storage node 103 or a storage device 133 within a storage node 103. The data protection control unit 186 may achieve redundancy through mirroring, RAID, or Erasure Coding. The redundancy level can be 1 or higher.

[0037] As described above, the storage controller 183 is a higher-level program, and the data protection control unit 186 is a lower-level program.

[0038] Figure 4 illustrates an example of data protection in the storage system 100. The example shown in Figure 4 provides data protection through mirroring between storage nodes. Figure 4 shows a host device 101 running the application program 111 and two storage nodes 103A and 103B.

[0039] The host device 101 is a general-purpose computer device that sends read requests or write requests (also called I / O (Input Output) requests) to the storage node 103 in response to user operations, implemented application programs 111, etc. The host device 101 may also be a virtual computer device, such as a virtual machine.

[0040] Node 103A is running the active storage controller 183A. The active storage controller 183A provides a logical volume (VOL) 211 to the host device 101. The logical volume is constructed by bundling one or more physical storage devices 133A (cloud storage service). The application program (APP) 111 specifies the destination address of the logical volume 211 and sends user data (host data) 201 to the storage node 103A.

[0041] User data 201 is cached in memory 136A and then logically stored in logical volume 211. Storage controller 183A also transfers user data 201 to the standby storage controller 183B, which forms part of the group (pair). Storage controller 183B caches the received user data 201 in memory 136B.

[0042] The data protection control unit 186A of node 103A generates a data integrity code, DIF (Data Integrity Field) 203, from the user data 201. The DIF 203, along with the user data 201, is stored in the physical storage device 133A of node 103A.

[0043] The data protection control unit 186A transfers the user data 201 to the data protection control unit 186B of node 103B. The data protection control unit 186B generates a DIF 203 from the received user data 201. The DIF 203, along with the user data 201, is stored in the physical storage device 133B of node 103B. In this way, the data protection control units 186A and 186B mirror (redundant) the user data 201 between storage nodes 103A and 103B.

[0044] Figure 5 schematically shows the configuration of the storage area of ​​the storage device 133 or the cloud block storage service 132. The storage area of ​​the storage device 133 is managed by addresses (LBAs) and includes three sub-areas: the data storage area 331, the DIF storage area 332, and the log area 333. Each area is a contiguous LBA area. The data storage area 331 is the area for storing user data. The DIF storage area 332 is the area for storing DIFs generated from user data. The log area 333 is the area used when storing DIFs on the drive.

[0045] In the example shown in Figure 5, an 8-byte DIF is generated for 512 bytes of user data. The 8-byte DIF corresponds one-to-one with the 512 bytes of user data. The DIF includes information such as CRC and LBA (Logical Block Address), as in T10DIF. The storage area of ​​storage device 133 is accessed in units of 512 bytes of sectors. Therefore, the 512-byte user data and the 8-byte DIF are stored in different areas. Note that the sector size of storage device 133 and the size of the DIF are not limited to these values.

[0046] A storage node 103 according to one embodiment of this specification selectively performs log-write type write processing and write processing utilizing atomic write functionality. These two types of write processing will be described below.

[0047] Figure 6 illustrates the write processing flow of the log-write method. An example is shown where an 8KB (8192B) write I / O is received from the host device 101.

[0048] The storage controller 183 receives user data from the host device 101 and caches it in memory 136. The storage controller 183 requests the data protection control unit 186 to destage the data 201 (store it in the storage device 133) (S1).

[0049] The data protection control unit 186 sends a mirroring request to the standby node 103 of the same group (S2). Specifically, the data protection control unit 186 sends a destaging request along with the data 201.

[0050] The data protection control unit 186 reads the DIF from the storage device 133 (S3). Since the host write size is 8KB, the corresponding DIF is 128B. Data is read from the storage device 133 in units of 512B. In this example, the DIF to be updated is 128B, so 512B of DIF data 211, including the DIF to be updated, is read from the DIF storage area 332.

[0051] The data protection control unit 186 generates a DIF from the received data 201 and updates the 512B DIF data 211 read from the DIF storage area 332 (S4). Furthermore, the data protection control unit 186 creates a log 213 of the updated DIF data 211 (S5). The log 213 includes the DIF data 211 (a copy thereof), information on its storage location, and the CRC. The data protection control unit 186 stores the 512B DIF data 211 in the log area 333 (S6).

[0052] Next, the data protection control unit 186 stores the DIF data 211 in the DIF storage area 332 (S7). Finally, the data protection control unit 186 stores the user data 201 in the data storage area 331 (S8).

[0053] Log 213 prevents shorn writes to the DIF. As mentioned above, the DIF is updated in 512B sector units, so if the size of the DIF to be updated is small, DIFs that are not intended for writing will also be updated. If a power outage occurs during data writing, the data in the storage device 133 will be in a partially written state (shorn write), and areas not intended for updating may be lost. Therefore, when reading, modifying, and writing the DIF in 512B units, the DIF is first written to the log area 333, and then the DIF storage area 332 is updated. In the event of a power failure, corrupted DIFs are recovered from the log.

[0054] Figure 7 illustrates the write processing flow using the atomic write function. There are requirements for using the atomic write function. Specifically, the data size that can be atomically written is limited to specific values, such as 4KB, 8KB, and 16KB. Furthermore, the start and end addresses of the atomic write update range must coincide with the address boundaries of that size (4K, 8K, or 16K).

[0055] For example, if the update range is 16KB, the start and end addresses must coincide with address boundaries every 16KB. Address boundaries are fixed within the storage area. The number of available sizes can be one or more arbitrary values. For example, each of the multiple sizes may be an integer multiple of the smallest size.

[0056] Figure 7 illustrates a case where an 8KB write I / O is received from the host device 101. Steps S1 and S2 are the same as steps S1 and S2 described with reference to Figure 6.

[0057] Next, the data protection control unit 186 reads the DIF from the storage device 133 (S13). In this example, the data protection control unit 186 adjusts the size of the data to be read to meet the requirements of the atomic write function. Here, the requirements for executing the atomic write function are that the size of the data to be written is 16KB and the address (LBA) of the data to be written coincides with a 16KB address boundary.

[0058] The data protection control unit 186 reads DIF data 221 from the DIF storage area 332 that includes the area to be updated and fits within a range of 16KB in size and address boundaries (S13).

[0059] The data protection control unit 186 generates a DIF from the received data 201 and updates the DIF data 221 read from the DIF storage area 332 (S14). Next, the data protection control unit 186 stores the updated DIF data 221 in the DIF storage area 332 (S15). Finally, the data protection control unit 186 stores the user data 201 in the data storage area 331 (S16).

[0060] Compared to the log-write method explained with reference to Figure 6, the write process using atomic write expands the size of the read-modified DIF data being written. Specifically, it expands from 512B to 16KB. Furthermore, the write process using atomic write does not require the creation of logs. The atomic write function guarantees that even if a power failure occurs during DIF writing, the data state will be the same as before writing. Therefore, the risk of DIF corruption due to shorn write is eliminated, making logging unnecessary.

[0061] Next, we will explain the selection of a light processing method from the log-light method and the atomic-light method. Figure 8A illustrates the selection of the atomic-light method, and Figure 8B illustrates the selection of the log-light method.

[0062] The data protection control unit 186 calculates the DIF write parameters (write address position (LBA) and data size) from the user data write parameters (write address position (LBA) and data size). Based on the results, the data protection control unit 186 selects either the atomic write method or the log write method.

[0063] As an example, consider a case where atomic write requirements include a 16KB address boundary and size constraint. Note that if multiple atomic write sizes exist, such as 4KB, 8KB, and 16KB, the maximum value among these may be used to determine whether atomic write is permitted.

[0064] The data protection control unit 186 determines whether the DIF update target area 251 straddles a 16KB address boundary (the boundary for the requirement to use atomic write). The DIF update target area 251 has a size that is an integer multiple of 512B, and all or part of it is the DIF data that is actually updated. In Figure 8A, the DIF update target area 251 does not straddle a 16KB address boundary, but is contained within a 16KB area between adjacent boundaries (the nth and (n+1th) address boundaries). Therefore, the data protection control unit 186 selects the atomic write method.

[0065] The data protection control unit 186 reads 16KB of DIF data 252, defined by adjacent address boundaries and including the DIF update target area 251, from the DIF storage area 332 to satisfy the 16KB size requirement (S21). In other words, the range read is the area obtained by adding a specific range to the DIF update target area 251.

[0066] The data protection control unit 186 updates the DIF to be updated in the read extended range DIF data 252 (S22), and uses the atomic write function to write the entire updated extended range DIF data 252 to the DIF storage area 332.

[0067] On the other hand, as shown in Figure 8B, if the DIF update target area 251 crosses a 16KB address boundary (the boundary for the requirement to use atomic write), the data protection control unit 186 determines that the atomic write function cannot be applied and selects the log write method.

[0068] The data protection control unit 186 reads the DIF data from the DIF update target area 251 from the DIF storage area 332 (S31). The data protection control unit 186 updates the read DIF data (S32), generates a log 255 of the updated DIF data, and writes it to the log area 333 (S33). Subsequently, the data protection control unit 186 writes the updated DIF data to the same address area of ​​the DIF storage area 332.

[0069] The management information held and used in the storage node 103 is described below. The management information may be stored in memory 136 and may be stored in storage device 133 or other non-volatile storage area.

[0070] Figure 9 shows an example configuration of the volume management table 410. The volume management table 410 manages information about logical volumes that the storage node 103 provides to the host device 101. More specifically, it manages the correspondence between the logical storage area of ​​a logical volume and the physical storage area of ​​a storage device.

[0071] In the configuration example shown in Figure 9, the volume management table 410 has a volume number column 411, a size column 412, a start offset column 413, a drive number column 414, and an offset column.

[0072] The volume number column 411 indicates a number that identifies the logical volume. The size column 412 indicates the capacity of the logical volume. The start offset column 413 indicates the starting address of the storage area in the logical volume. The drive number column 414 and the offset column 415 indicate a number that identifies the storage device and the starting address of the storage area in the storage device.

[0073] Figure 10 shows an example of the configuration of the memory device area management table 420. The memory device area management table 420 manages the area breakdown of physical memory devices. The memory device area management table 420 is maintained for each memory device.

[0074] In the configuration example shown in Figure 10, the storage device area management table 420 has a classification column 421, a start offset column 422, and a size column 423. The classification column 421 indicates the type of storage area, that is, the type of data stored in the storage area. As described above, the storage area of ​​the storage device includes a data storage area 331, a DIF storage area 332, and a log area 333. The start offset column 422 and the size column 423 indicate the start address position and size of the storage area, respectively. In Figure 10, for ease of illustration, the start offset is expressed in terms of data volume rather than LBA.

[0075] Figure 11 shows an example configuration of the atomic write requirements management table 430. The atomic write requirements management table 430 manages the constraints (usage requirements) of the atomic write function. In the example configuration of Figure 11, the atomic write requirements management table 430 has a size column 431 and a boundary column 432. The size column 431 indicates the data size for which the atomic write function is permitted to be used, and the boundary column 432 indicates the location of the address boundary (requirement boundary) for which the atomic write function is permitted to be used. The requirement boundary (address) for atomic write may be, for example, an integer multiple of the value indicated in the boundary column 432. Note that the address of the requirement boundary does not have to be an integer multiple of the size.

[0076] The data protection control unit 186 refers to the atomic write requirements management table 430 to determine whether the atomic write function can be used and the amount of adjustment (extension range) of the access range to the storage device 133.

[0077] The processing of the storage node 103 will be explained below with reference to a flowchart. Figure 12 shows an example flowchart of the write process of the storage system 100. The storage node (also called the active node) running the active storage controller 183 receives a write request from the host device 101 (S101), and also receives host data (also simply called data). The active storage controller 183 stores the received data in the cache area of ​​memory 136 (S102).

[0078] The active storage controller 183 transfers the received host data and control parameters indicating the address of the host data to the storage node 103 (referred to as the standby node) running the standby controller 183 (S104). The transferred data is cached on the standby node 103 for redundancy.

[0079] Next, the active storage controller 183 returns a write completion response to the host device 101. Subsequently, the active node 103 and the standby node 103 perform destaging (S105).

[0080] Figure 13 shows an example flowchart of the destaging process S105 in Figure 12. The data protection control unit 186 of the active node 103 requests the standby node 103 to store the host data received from the host device 101 for redundancy (mirroring) (S111). At this time, a destaging request is sent along with control information including parameters indicating the storage destination and the host data.

[0081] The data protection control unit 186 of the standby node 103 executes the DIF drive storage process (DIF update process) (S112), and then executes the host data drive storage process (data update process) (S113). After that, the data protection control unit 186 of the standby node 103 returns a completion response for the request processing to the active node 103 (S114).

[0082] Upon receiving the completion response, the data protection control unit 186 of the active node 103 executes the DIF drive storage process (DIF update process) (S115), and then executes the host data drive storage process (data update process) (S116).

[0083] Figure 14 shows an example flowchart of the DIF drive storage process S112 and S115 in Figure 13. The data protection control unit 186 calculates the DIF parameters, specifically the offset (start address) and size of the DIF update target area in the DIF storage area 332, from the host data to be destaged. The relationship between the storage address of the host data and the storage address of its DIF (and how this relationship is determined) is predetermined.

[0084] The data protection control unit 186 determines whether the size and boundaries of the DIF update target area match the atomic write requirements (S132). Specifically, the data protection control unit 186 refers to the atomic write requirements management table 430 to determine whether the size and boundaries of the DIF update target area match.

[0085] If a match is found (S132: YES), the data protection control unit 186 determines that atomic write is possible, generates a DIF from the host data (S133), and writes the generated DIF to the DIF storage area 332 using atomic write. At this time, a read modifier is not required.

[0086] If the size and boundaries of the area to be updated do not perfectly match the atomic write requirements (S132: NO), the data protection control unit 186 determines whether the DIF write parameters (addresses at both ends of the write area) can be adjusted to meet the atomic write requirements (S135). Specifically, as explained with reference to Figures 8A and 8B, the data protection control unit 186 determines whether the area to be updated crosses the boundary of the largest size (16KB in this example) among the boundary constraints of the atomic write requirements (S135).

[0087] If the DIF update target area does not cross the boundary of the maximum size (S135: YES), the data protection control unit 186 determines that atomic write is available and extends the DIF read range (S135). If there are atomic write requirements of multiple sizes, the drive selects the size with the smallest read range.

[0088] Here, let's assume that atomic access requirements for three sizes—4KB, 8KB, and 16KB—are defined. The data protection control unit 186 determines whether the DIF update target area crosses the 8KB boundary. If the DIF update target area crosses the 8KB boundary, the data protection control unit 186 selects 16KB access.

[0089] If the DIF update target area does not cross an 8KB boundary, the data protection control unit 186 determines whether the DIF update target area crosses a 4KB boundary. If the DIF update target area crosses a 4KB boundary, the data protection control unit 186 selects 8KB access. If the DIF update target area does not cross a 4KB boundary, the data protection control unit 186 selects 4KB access for the DIF update target area.

[0090] In this way, by sequentially determining whether the DIF update area overlaps with the requirement boundary, starting from the largest boundary, it becomes possible to select the smallest read-modify area that includes the DIF update target area and is atomically writeable, thereby reducing the amount of data transferred.

[0091] The data protection control unit 186 generates a DIF from the host data, reads the DIF data of the determined size and area from the DIF storage area 332, and updates it with the generated DIF (S138). Then, it writes the updated DIF data back to the same address in the DIF storage area 332 (S144).

[0092] In step S135, if the DIF update area crosses a 16KB boundary (S135:NO), the data protection control unit 186 determines that atomic write is unavailable and performs a log write. Specifically, the data protection control unit 186 reads DIF data of an integer multiple size of 512B (DIF data of the DIF update area) from the DIF storage area 332 and updates the read DIF data with the generated DIF (S138). After that, the data protection control unit 186 creates a write log and stores it in the log area 333 (S139), and then writes the updated DIF data to the DIF storage area 332 (S140). At this time, the atomic write function is not used.

[0093] As described above, this embodiment utilizes the atomic write function for DIF updates. This reduces the processing load for DIF updates. Furthermore, by comparing the DIF update target area with the atomic write requirements, it is possible to appropriately determine which DIF updates can utilize the atomic write function. In addition, if multiple atomic write requirements of different sizes exist, the amount of data transferred can be reduced by selecting the smallest available size.

[0094] If atomic write is not used, a data writing method different from the log write method may be used. This embodiment explains the use of the atomic write function in writing DIF data, but the atomic write function may or may not be used when writing host data. [Examples]

[0095] In Example 1, the active node 103 and the standby node 103 each perform DIF write method determination and DIF generation processing. This enables simple control. In Example 2, the active node 103 performs write method determination and DIF generation processing, and transfers the DIF generation processing result to the standby node 103. In addition to the host data, the generated DIF is also transferred from the active node 103 to the standby node 103. Note that the write method determination result may or may not be transmitted.

[0096] The standby node 103 rewrites the address information of the received DIF data and stores it in the DIF storage area 332. This eliminates the need for read processing from the storage device associated with DIF generation at the standby node 103, compared to Embodiment 1.

[0097] Figure 15 shows an example flowchart of the destaging process in Embodiment 2. In the active node 103, the data protection control unit 186 determines the write method for the DIF (S151) and then generates the DIF from the host data (S152). Step S151 may be described by referring to steps S131, S132, and S135 in the flowchart of Figure 14. Step S152 may be described by referring to steps S133, S136, S137, and S138 in the flowchart of Figure 14.

[0098] Next, the data protection control unit 186 of the active node 103 requests the standby node 103 to store the host data and DIF (S153). At this time, the host data and DIF data are sent. The transferred DIF data is data that can be written directly to the DIF storage area 332 using either the atomic write method or the log write method.

[0099] Upon receiving the request, the standby node 103 executes the drive storage process for the DIF (S154) and the drive storage process for the host data (S155). After these operations, the data protection control unit 186 returns a completion response to the active node 103 (S156).

[0100] Upon receiving a completion response, the active node 103 executes the DIF drive storage process S157 and the host data drive storage process S158. Step S157 may be described with reference to the explanations in S134, S139, and S140.

[0101] Figure 16 shows an example flowchart of the DIF drive storage process S154 at the standby node 103 in Figure 15. The data protection control unit 186 determines whether or not to use the atomic write function based on the DIF received from the active node 103 (S171). The data protection control unit 186 may determine the atomic write requirement in the same way as in step S132 in Figure 14, or the write method may be notified by the active node 103.

[0102] If the DIF is capable of atomic writing (S171: YES), the data protection control unit 186 rewrites the necessary parts of the DIF's write parameters (S172) and writes them to the drive's DIF storage area (S173). In the standby node 103, the storage address in the DIF storage area 332 may change, so the DIF's address information is updated as needed.

[0103] If atomic write is not possible for the DIF (S171: NO), the data protection control unit 186 writes the DIF to the DIF storage area 332 using the log write method. Specifically, the data protection control unit 186 rewrites the necessary parts of the address information of the DIF (S174), creates a log, and writes it to the log area 333 (S175). After that, the data protection control unit 186 writes the DIF to the DIF storage area 332 (S176).

[0104] If the log-write method is selected, the DIF data may not be transferred, and the determination result may be sent to the standby node 103. The standby node 103 generates a DIF from the host data and performs DIF writing using the log-write method as described with reference to Figure 13.

[0105] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.

[0106] Furthermore, some or all of the above configurations, functions, and processing units may be implemented in hardware, for example, by designing them as integrated circuits. Alternatively, the above configurations and functions may be implemented in software by having the processor interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD, or a recording medium such as an IC card or SD card.

[0107] Furthermore, the control lines and information lines shown are those deemed necessary for explanatory purposes, and not all control lines and information lines are necessarily shown in the actual product. In reality, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0108] 103 Storage Nodes 131 Cloud Compute Services 132 Cloud Block Storage Service 133 Storage Devices 135 CPU 136 memory 331 Data storage area 332 DIF storage area 333 Log area

Claims

1. It is a storage system, It includes a processor and memory, Atomic writes are possible, which guarantee the data before the update during data update writing. The aforementioned processor, Based on the write parameters of the data guarantee code of the user data to be updated and written, it is determined whether to apply the atomic write. If it is determined that the atomic write should be applied, the update write of the data guarantee code using the atomic write is performed. A storage system that, if it is determined not to apply the atomic write, writes log data including a copy of the data assurance code, and then performs an update write of the data assurance code.

2. A storage system according to claim 1, The aforementioned processor, Based on the user data write parameters, the write parameters of the data guarantee code are determined, including the start and end positions of the update target area of ​​the data guarantee code in the physical storage area. Based on the start position and the end position, it is determined whether to apply the atomic write to the area to be updated. Storage system.

3. A storage system according to claim 2, If the start and end positions of the update target area are located between adjacent address boundaries as defined by the atomic write requirements, A storage system in which the processor extends the range read from the physical storage area for read-modify-write of the area to be updated to the area between the adjacent address boundaries that include the area to be updated.

4. A storage system according to claim 3, The requirements for atomic write described above specify address boundaries for each of the multiple data sizes, The processor is a storage system that performs a read-modify-write operation on the area to be updated, selecting the smallest data size that satisfies the requirements of the atomic write operation for the area to be updated.

5. A storage system according to claim 2, The processor is a storage system that determines that a write to the area to be updated does not satisfy the requirements of an atomic write if the area to be updated straddles an address boundary indicated by the requirements of an atomic write.

6. A storage system according to claim 2, The requirements for atomic write described above specify address boundaries for each of the multiple data sizes, The processor determines that writing to the area to be updated does not satisfy the requirements for an atomic write when the area to be updated spans the address boundary of the largest size among the multiple data sizes.

7. A storage system according to claim 1, A first storage node including the processor and the memory, and a second storage node, The aforementioned second storage node is The user data is received from the first storage node. Based on the user data writing parameters, the start and end positions of the data guarantee code update target area in the physical storage area are determined. Based on the aforementioned start position and end position, it is determined whether writing to the update target area can satisfy the requirements of an atomic write. A storage system that, when it determines that writing to the area to be updated can satisfy the requirements of an atomic write, executes a write to the area to be updated using the atomic write.

8. A storage system according to claim 1, A first storage node including the processor and the memory, and a second storage node, The aforementioned second storage node is The first storage node receives the user data, The first storage node receives data to be written to the physical storage area for updating the data assurance code. A storage system that writes the user data and the data to be written to the physical storage area to different areas of the physical storage area.

9. A method for controlling the writing of data assurance codes to a physical storage area in a storage system, Based on the write parameters of the data guarantee code for the user data being updated, it is determined whether to apply atomic write, which guarantees the data before the update, during the data update write. If it is determined that the atomic write should be applied, the update write of the data guarantee code using the atomic write is performed. A method in which, if it is determined that the atomic write should not be applied, an update write of the data guarantee code is performed after writing log data including a copy of the data guarantee code.

Images