System and method for writing logs on disk in logical device

Abstract

The invention relates to a system and a method for writing a log on a disk in a logic device. The system may include one or more processors configured to receive a write operation to write a data block to a logic device established using one or more storage devices that retain one or more data stripes and one or more metadata blocks to store data of a write log. The one or more processors may identify a first data stripe of the data block to be written to a first storage device of the one or more storage devices, write a copy of the first data stripe to a data stripe of the one or more data stripes retained on the first storage device, metadata associated with the data block is written to a metadata block of the one or more metadata blocks retained on the first storage device, and the write operation is performed to store the data block across the one or more storage devices.

Description

Technical Field

[0001] The present disclosure relates generally to systems and methods for write logging in logical devices, and more particularly to providing on-disk write logging without battery backup. Background Art

[0002] Redundant Array of Independent Disks (RAID) can use data mirroring and / or data parity to provide data redundancy. RAID can store user data across participating disk stripes and keep mirroring and / or parity data consistent to help recover data from a failed disk. Whenever user data is written on a logical disk (or logical device), the RAID controller can perform the work of striping data and updating parity. In this way, RAID can keep parity synchronized with data, which helps to regenerate data in the event of a failure of any of the disks. In the event of a double failure (e.g., a disk failure after a controller power failure), parity may be in an inconsistent state. In the event of a disk failure, inconsistent parity cannot be reliably used for recovery. Summary of the invention

[0003] In one aspect, the present disclosure relates to a system comprising: one or more processors configured to: receive a write operation to write a data block to a logical device established using one or more storage devices, the one or more storage devices retaining one or more data stripes and one or more metadata blocks to store data of one or more write logs, identify a first data stripe of the data block to be written to a first storage device in the one or more storage devices, write a copy of the first data stripe to a data stripe in the one or more data stripes retained on the first storage device, write metadata related to the data block to a metadata block in the one or more metadata blocks retained on the first storage device, and perform the write operation to store the data block across the one or more storage devices.

[0004] In another aspect, the present disclosure relates to a method, comprising: receiving a write operation by one or more processors to write a data block to a logical device established using one or more storage devices, the one or more storage devices retaining one or more data stripes and one or more metadata blocks to store data of one or more write logs; identifying by the one or more processors a first data stripe of the data block to be written to a first storage device in the one or more storage devices; writing by the one or more processors a copy of the first data stripe to a data stripe in the one or more data stripes retained on the first storage device; writing by the one or more processors metadata related to the data block to a metadata block in the one or more metadata blocks retained on the first storage device; and executing by the one or more processors the write operation to store the data block across the one or more storage devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Various objects, aspects, features and advantages of the present disclosure will become more apparent and better understood by reference to the detailed description taken in conjunction with the accompanying drawings, in which like reference characters identify corresponding elements throughout the text. In the drawings, like reference numerals generally indicate identical, functionally similar and / or structurally similar elements.

[0006] Figure 1A is a schematic block diagram of a system including an example RAID configuration according to an embodiment.

[0007] Figure 1B is a schematic block diagram of a computing system according to an embodiment.

[0008] Figure 2 is a schematic block diagram of a system for performing on-disk write logging according to an embodiment.

[0009] Figure 3 is a schematic block diagram of a system for performing on-disk write logging according to an embodiment.

[0010] Figure 4A and Figure 4B is a schematic block diagram of a layout of metadata blocks for writing logs according to an embodiment.

[0011] Figure 5 is a flow chart showing a process for writing new data on a disk according to an embodiment.

[0012] Figure 6 is a flow chart showing a process for log recovery according to an embodiment.

[0013] Figure 7 is a flow chart showing a process for writing logs on disk according to an embodiment.

[0014] The details of various embodiments of the method and system are set forth in the accompanying drawings and the description below. DETAILED DESCRIPTION

[0015] The following disclosure provides many different embodiments or examples for implementing the different features of the provided subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. Of course, these are only examples and are not intended to be restrictive. For example, the following description in which a first feature communicates or is communicatively coupled to a second feature may include an embodiment in which the first feature directly communicates with the second feature or is directly coupled to the second feature, and may also include an embodiment in which an additional feature may be between the first and second features, so that the first feature indirectly communicates with the second feature or is indirectly coupled to the second feature. In addition, the present disclosure may repeat reference numbers and / or letters in various examples. This repetition is for the purpose of simplicity and clarity, and does not itself indicate the relationship between the various embodiments and / or configurations discussed.

[0016] Various embodiments disclosed herein relate to a system comprising one or more processors, one or more processors configured to receive a write operation to write a data block to a logical device established using one or more storage devices. In some embodiments, a logical device can be established by forming, defining or representing a logical device (or a range of data blocks) across one or more storage devices. In some embodiments, a data block may be a sequence of bytes or bits of data, or any data structured logically or physically. In some embodiments, a storage device may be one or more volatile memory devices, one or more non-volatile memory devices, one or more disks, one or more magneto-optical disks, one or more hard disk drives (HDDs), one or more solid-state drives (SSDs), RAID, or any device suitable for storing computer-readable data. In some embodiments, a logical device (also referred to as a "logical disk", "virtual device" or "virtual disk") may be a range of data stored in a storage device and represented or provided as a device to a host or user (e.g., a range of continuous data blocks). For example, in a RAID, a logical device may refer to a range of continuous stripes to represent a device to a host driver, where a stripe is defined as a data block across all spans in a RAID configuration. A span may be an array, and multiple spans may be combined to form a logical device with nested RAID levels. In other words, in RAID, a logical device may be formed across all spans in a RAID configuration.

[0017] One or more storage devices may retain one or more data stripes and one or more metadata blocks to store data written to the log. In some embodiments, one or more data stripes and one or more metadata blocks may be retained by splitting, maintaining or saving disk space for writing log data from one or more storage devices. In some embodiments, the write log may be a record being written, or any one or more data records or blocks that track one or more ongoing write transactions. In some embodiments, one or more data stripes may be one or more data blocks in a logical device or physical storage device. In RAID, a data stripe may refer to a data block in each arm of a RAID array (or arrays), such that the data stripes above the array of multiple arms form or define data rows. An arm may refer to a device used to form or define an array (used as an element of an array) in a RAID configuration.

[0018] The one or more processors may be configured to identify a first data stripe of data blocks to be written to a first storage device in one or more storage devices. The one or more processors may be configured to write a copy of the first data stripe to a data stripe in one or more data stripes retained on the first storage device. The one or more processors may be configured to write metadata associated with the data block to a metadata block in one or more metadata blocks retained on the first storage device. In some embodiments, the metadata block may include data in a logical device or in a storage device that provides information about other data such as data written to a log. The one or more processors may be configured to perform a write operation to store the data block across the one or more storage devices.

[0019] In some embodiments, when performing a write operation, the one or more processors may be configured to write a first data stripe of data blocks at a location on the first storage device. The location of the first data stripe written on the first storage device may be different from the location of the data stripe in the one or more data stripes retained on the first storage device. In some embodiments, the location of the first data stripe may be a location of the data blocks stored on the storage device using logical block addressing (LBA), linear addressing, logical addressing, physical addressing, or any addressing scheme for the storage device.

[0020] In some embodiments, metadata associated with a data block may include location information of the data block. In some embodiments, the location information of the data block may be a location of the data block stored on a storage device using LBA, linear addressing, logical addressing, physical addressing, or any addressing scheme for the storage device. In some embodiments, a first data stripe of a data block may include one of parity data or non-parity data. In some embodiments, parity data may be data indicating whether the number of bits having a specific logic value (e.g., "1") in other data is even or odd, data indicating the result of an XOR operation on other data, or any data used to verify the integrity of other data.

[0021] In some embodiments, one or more processors may be configured to identify a second data stripe of a data block to be written to a second storage device in one or more storage devices. One or more processors may be configured to write a copy of the second data stripe to a data stripe in one or more data stripes retained on the second storage device, and write metadata associated with the data block to a metadata block in one or more metadata blocks retained on the second storage device. When performing a write operation, the one or more processors may be configured to write the second data stripe of the data block at a location on the second storage device that is different from the location of the data stripe in one or more data stripes retained on the second storage device. The metadata may include first mapping data identifying which portion of the first storage device is to be modified due to the write operation, and second mapping data identifying which portion of the second storage device is to be modified due to the write operation. Each of the first mapping data and the second mapping data may be a bitmap. In some embodiments, the mapping data may be data indicating a mapping from a domain (e.g., a data block) to a corresponding state of the domain (e.g., a bit indicating a modified state of the data block).

[0022] In some embodiments, one or more processors may be configured to detect an inconsistent state of one or more storage devices. In some embodiments, the inconsistent state of one or more storage devices may indicate a state in which data on one of a plurality of redundant data blocks (e.g., data on a first data stripe) is changed but data on another of a plurality of redundant data blocks (e.g., data on a second data stripe) is not changed, or any state in which one or more data blocks are inconsistent with other one or more data blocks in one or more storage devices. In response to the detection, the one or more processors may be configured to determine whether the metadata block is turned on or off. In response to determining that the metadata block is turned on, the one or more processors may be configured to read the metadata block to obtain location information of a copy of the first data stripe and a copy of the second data stripe stored in the first storage device and the second storage device, respectively. The one or more processors may be configured to write a copy of the first data stripe to the first storage device based on the location information, and write a copy of the second data stripe to the second storage device. In response to writing a copy of the first data stripe and a copy of the second data stripe, the one or more processors may be configured to indicate the metadata block as closed.

[0023] Various embodiments disclosed herein relate to a method. The method includes receiving a write operation by one or more processors to write a data block to a logical device established using one or more storage devices. The one or more storage devices may retain one or more data stripes and one or more metadata blocks to store data written to a log. The method may include identifying, by one or more processors, a first data stripe of a data block to be written to a first storage device in one or more storage devices. The method may include writing, by one or more processors, a copy of the first data stripe to a data stripe in one or more data stripes retained on the first storage device. The method may include writing, by one or more processors, metadata associated with the data block to a metadata block in one or more metadata blocks retained on the first storage device. The method may include performing a write operation by one or more processors to store the data block across one or more storage devices.

[0024] In some embodiments, when performing a write operation, the one or more processors may write a first data stripe of the data block at a location on the first storage device that is different from a location of a data stripe in the one or more data stripes retained on the first storage device. In some embodiments, metadata associated with the data block may include location information of the data block. In some embodiments, the first data stripe of the data block may include one of parity data or non-parity data.

[0025] In some embodiments, one or more processors may identify a second data stripe of a data block to be written to a second storage device in one or more storage devices. The one or more processors may write a copy of the second data stripe to a data stripe in one or more data stripes retained on the second storage device. The one or more processors may write metadata associated with the data block to a metadata block in one or more metadata blocks retained on the second storage device. When performing a write operation, the one or more processors may write the second data stripe of the data block at a location on the second storage device that is different from the location of the data stripe in one or more data stripes retained on the second storage device. The metadata may include first mapping data identifying which portion of the first storage device is to be modified due to the write operation, and second mapping data identifying which portion of the second storage device is to be modified due to the write operation. Each of the first mapping data and the second mapping data may be a bitmap.

[0026] In some embodiments, one or more processors may detect an inconsistent state of one or more storage devices. In response to the detection, the one or more processors may determine whether the metadata block is open or closed. In response to determining that the metadata block is open, the one or more processors may read the metadata block to obtain location information of a copy of a first data stripe and a copy of a second data stripe stored in a first storage device and a second storage device, respectively. The one or more processors may write a copy of the first data stripe to the first storage device and a copy of the second data stripe to the second storage device based on the location information. In response to writing the copy of the first data stripe and the copy of the second data stripe, the one or more processors may indicate the metadata block as closed.

[0027] RAID (Redundant Array of Independent Disks; also referred to as a "RAID array" or "array") may use data mirroring and / or data parity to provide data redundancy. RAID may store user data striped across participating disks and keep mirror and / or parity data consistent to help recover data from a failed disk. Striping may be any operation that defines one or more data blocks across an array (or multiple arrays) as combined data blocks (e.g., referred to as a "stripe"). Whenever user data is written on a logical disk (or logical device), a RAID controller may perform the work of striping the data and updating the parity. In this way, RAID may keep the parity synchronized with the data, which helps to regenerate the data in the event that any of the disks fails. In the case of a RAID 1 logical device or disk (LD), data may be stored in a data arm (or data disk) and mirrored to a mirror arm. In some embodiments, a data arm may store the original data, and a mirror arm may store a copy of the original data. In the case of a RAID 5LD, data may be distributed and striped across multiple arms (or disks). In Figure 1A and Figure 1B An example configuration of a RAID system (eg, RAID 5) is shown in FIG.

[0028] Figure 1A 1 is a schematic block diagram of a system 100 including an example RAID configuration according to an embodiment. The system 100 may include a host 120, a RAID controller 140, and a RAID 150. Each of the host 120, the RAID controller 140, and the RAID 150 may have Figure 1B The configuration of the computing system in FIG. 1 is similar to that of FIG. 1 , but it need not have any Figure 1B The host 120 may include one or more applications 122 and a host driver 124. Each of the one or more applications 122 and the host driver 124 may be implemented in hardware, software, firmware, or any combination thereof. The one or more applications 122 may send commands to one or more logical devices or disks (LD) or one or more physical devices or disks (PD) in the RAID 150 via the host driver 124 and the RAID controller 140. During host driver negotiation, the host driver 124 may allocate one or more host buffers in the (host's) memory to transfer input, data, and status between the application and the RAID controller 140.

[0029] In some embodiments, RAID 150 may include a single span 3 disk RAID 5 logical device (LD). That is, RAID 150 may include multiple spans (e.g., span 0, span 1, span 2, each including 3 arms (or disks)) so that a single span may form a LD. For example, span 0 may include arm 0, arm 1, and arm 2. Each arm may include N stripes, including data stripes (e.g., data stripe 151) and parity stripes (e.g., parity stripe 153), and a disk drive format (DDF) block (e.g., DDF block 154). DDF block 154 may contain metadata information about the LD (e.g., LD metadata information according to the SNIA [Storage Networking Industry Association] specification). Each data stripe (e.g., data stripe 0) may be distributed and stored on two arms (e.g., data stripe 151 on arm 0 and data stripe 152 on arm 1), and a parity stripe (e.g., parity stripe 153) corresponding to the data stripe (e.g., data stripe 0) may be stored on the remaining arm (e.g., arm 3). Data stored on span 0 may be mirrored on each of span 1 and span 2. Data blocks across all spans (e.g., data stripe 0 and parity stripe 0 in spans 0 to 2) may form an LD stripe (e.g., stripe 0) such that the size of the stripe is equal to the number of arms multiplied by the size of the stripe.

[0030] Figure 1B1 is a schematic block diagram of a computing system according to an embodiment. The illustrated example computing system 1000 includes one or more processors 1010 communicating directly or indirectly with a memory 1060 via a communication system 1040 (e.g., a bus), at least one network interface controller 1030 having a network interface port for connecting to a network (not shown), and other components, such as input / output ("I / O") components 1050. Typically, the processor 1010 will execute instructions (or computer programs) received from the memory. The illustrated processor 1010 incorporates or is connected to a cache memory 1020. In some examples, instructions are read from the memory 106 into the cache memory 1020 and executed by the processor 1010 from the cache memory 1020. The computing system 1000 may not necessarily contain Figure 1B All of these components shown in the Figure 1B Other components not shown.

[0031] In more detail, processor 1010 may be any logic circuitry that processes instructions, for example, instructions retrieved from memory 1060 or cache 1020. In many embodiments, processor 1010 is a microprocessor unit or a dedicated processor. Computing device 1050 may be based on any processor or processor set capable of operating as described herein. Processor 1010 may be a single-core or multi-core processor. Processor 1010 may be a plurality of different processors.

[0032] The memory 1060 may be any device suitable for storing computer-readable data. The memory 1060 may be a device with fixed storage or a device for reading removable storage media. Examples include all forms of volatile memory (e.g., RAM), nonvolatile memory, media and memory devices, semiconductor memory devices (e.g., EPROM, EEPROM, SDRAM, and flash memory devices), magnetic disks, magneto-optical disks, and optical disks (e.g., CD ROM, DVD-ROM, or Blu-ray discs). Computing system 1000 may have any number of memory devices 1060 .

[0033] Cache memory 1020 is typically a form of computer memory placed near processor 1010 for fast read times. In some implementations, cache memory 1020 is part of processor 1010, or on the same chip as processor 1010. In some implementations, there are multiple levels of cache 1020, for example, L2 and L3 cache layers.

[0034] The network interface controller 1030 manages data exchange via a network interface (sometimes referred to as a network interface port). The network interface controller 1030 handles the physical and data link layers of the OSI model for network communication. In some embodiments, some of the tasks of the network interface controller are handled by one or more of the processors 1010. In some embodiments, the network interface controller 1030 is part of the processor 1010. In some embodiments, the computing system 1000 has multiple network interfaces controlled by a single controller 1030. In some embodiments, the computing system 105 has multiple network interface controllers 1030. In some embodiments, each network interface is a connection point for a physical network link (e.g., a Category 5 Ethernet link). In some embodiments, the network interface controller 1030 supports wireless network connections, and the interface port is a wireless (e.g., radio) receiver or transmitter (e.g., for any of IEEE 802.11 protocols, near field communication "NFC", Bluetooth, ANT, or any other wireless protocol). In some embodiments, the network interface controller 1030 implements one or more network protocols, such as Ethernet. Typically, computing device 1050 exchanges data with other computing devices via a physical or wireless link through a network interface. A network interface may be linked directly to another device or to another device via an intermediate device, such as a network device that connects computing device 1000 to a data network such as the Internet, such as a hub, bridge, switch, or router.

[0035] The computing system 1000 may include, or provide an interface for, one or more input or output ("I / O") devices. Input devices include, but are not limited to, keyboards, microphones, touch screens, foot pedals, sensors, MIDI devices, and pointing devices such as a mouse or trackball. Output devices include, but are not limited to, video displays, speakers, refreshable Braille terminals, lights, MIDI devices, and 2-D or 3-D printers.

[0036] Other components may include I / O interfaces, external serial device ports, and any additional coprocessors. For example, computing system 1000 may include interfaces (e.g., Universal Serial Bus (USB) interfaces) for connecting input devices, output devices, or additional memory devices (e.g., portable flash drives or external media drives). In some implementations, computing device 1000 includes additional devices, such as coprocessors, for example, math coprocessors that can assist processor 1010 with high-precision or complex calculations.

[0037] Component 1090 may be configured to connect to external media, display 1070, input device 1080, or any other component or combination thereof in computing system 1000. Display 1070 may be a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a flat panel display, a solid state display, a cathode ray tube (CRT) display, a projector, a printer, or other now known or later developed display device for outputting determined information. Display 1070 may serve as an interface for a user to view the operation of processor 1010, or specifically as an interface to interface with software stored in memory 1060.

[0038] The input device 1080 may be configured to allow a user to interact with any of the components of the computing system 1000. The input device 1080 may be a plurality of pads, a keyboard, a cursor control device (such as a mouse), or a joystick. In addition, the input device 1080 may be a remote control, a touch screen display (which may be a combination of the display 1070 and the input device 1080), or any other device operable to interact with the computing system 1000, such as any device operable to act as an interface between a user and the computing system 1000.

[0039] In one aspect, a RAID controller (e.g., RAID controller 140) may implement a write log mechanism to update the LD stripe in a consistent manner using the write log so that all new data blocks and parity blocks are updated atomically (e.g., (1) all new data blocks and parity blocks are updated together, or (2) neither new data blocks nor parity blocks are updated). In the event that a RAID process (e.g., a write operation) is interrupted due to a controller failure and / or a disk failure, the write log may be used to make the LD stripe consistent. As described in the following sections, existing write log mechanisms have some limitations.

[0040] Typically, a battery backup can be performed in a RAID controller to maintain data and write log data. If the battery backup is not available or is not performed correctly, then in a controller power failure scenario, the write log data may be at risk of being lost. A RAID controller that does not have a large cache memory (e.g., DRAM (dynamic random access memory)) does not have any way to retain the write log data. As an alternative, the RAID controller may maintain the write log data (without maintaining the actual data) in a controller persistent memory (e.g., nvSRAM (non-volatile static random access memory)). However, the size of such persistent memory may be limited. In addition, in the case of a double fault (e.g., a disk failure occurs after a (RAID) controller power failure), maintaining the write log data only in such a controller persistent memory may have the risk of losing or corrupting the data. In the case of a double fault, the parity may be in an inconsistent state, and inconsistent parity cannot be reliably used for recovery. In addition, a permanent controller failure (e.g., in the case of a need for replacement) may result in the complete loss of the write log data in the existing write log mechanism.

[0041] To address this issue, according to certain aspects, embodiments in the present disclosure relate to a technique for maintaining or maintaining write log data (or log information) on a disk rather than on a cache (e.g., DRAM) or persistent memory (e.g., nvSRAM) in a controller. In some embodiments, the write log data may be persisted on the same set of disks on which the LD is created. In some embodiments, the disk space used to write log data may be split (or reserved or maintained or saved) from all participating disks in the LD. For example, disk space from all participating disks in the LD may be used to maintain or save write log data.

[0042] In some embodiments, the disk (or device or arm for forming or defining an array) may have a layout for writing a log. In some embodiments, writing a log may be any one or more data records or blocks that write or keep a record of being written or keep tracking one or more ongoing write transactions. According to the layout, the disk may be divided into data or parity stripes (e.g., data stripes or parity stripes), write log data stripes, write log metadata blocks and / or parts of DDF blocks. In some embodiments, data can be located in the order of data or parity stripes, write log data stripes, write log metadata blocks and DDF blocks using an addressing scheme (e.g., logical block addressing (LBA)), but in other embodiments, data can be located in another order (e.g., in the order of data or parity stripes, write log metadata blocks, write log data stripes and DDF blocks). In some embodiments, disk LBAs can be grouped into stripes based on LD stripe size. For example, if LD has a 64KB stripe size on a physical device (PD) with 4KB LBA size, 16 consecutive LBAs can be grouped in a single stripe. For example, the first data or parity stripe (e.g., data or parity stripe 0) in the data or parity stripe may be stored at the first LBA, and the last block in the DDF block may be stored at the last LBA. The data or parity stripe may include (N+1) data or parity stripes (N is a positive integer), for example, data or parity stripe 0 to data or parity stripe N. The write log (WJ) data stripe may include (M+1) WJ data stripes (M is a positive integer), for example, WJ data stripe 0 to WJ data stripe M. The WJ metadata block may include (M+1) WJ metadata blocks, for example, WJ metadata block 0 to WJ metadata block M.

[0043] In some embodiments, each data or parity stripe on the disk may contain user data or parity data (in the case of a parity RAID LD). In some embodiments, some of the data or parity stripes may be split (or reserved or saved or maintained) for the WJ data stripes to maintain write log data. For example, disk space in the LD may be used to maintain, save or store WJ data stripes to maintain write log data. Each WJ data stripe may contain write log data for a data or parity stripe or data row corresponding to an arm or span. A data row (or row) may be defined as a block of data in a span (or array) such that the size of the row is equal to the number of arms per span multiplied by the stripe size. In some embodiments, a data block may be a unit for storing data on a storage device using logical block addressing (LBA), linear addressing, logical addressing, physical addressing, or any addressing scheme for the storage device. For example, referring to Figure 1A, data stripe 151, stripe 152, and parity stripe 153 form a data row. The number of stripes reserved for WJ data stripes may be determined based on the number of outstanding data row writes on the LD. In some embodiments, the number of stripes reserved for WJ data stripes may be derived from the number of outstanding host I / Os (input / outputs) for writing through the LD (e.g., writing data to both the RAID cache and the disk) or the number of outstanding row refreshes for writing back to the LD (e.g., writing data to the RAID cache and later or when necessary, writing the data to the disk).

[0044] In some embodiments, a WJ metadata block may be reserved for each of the WJ data stripes. The WJ metadata block may maintain, maintain or store metadata information of the write log data stored in the corresponding WJ data stripe. The WJ metadata block may include (1) LD number, (2) mapping information of the WJ data stripe to the corresponding data or parity stripe (in the span), and / or (3) validity information of blocks in the data or parity stripe of the write log of all disks (or arms) participating in the span. The validity information may include whether each LBA block is dirty (e.g., damaged or invalid or not the latest) or valid (e.g., the latest). The WJ metadata block may be replicated on all disks (or arms) participating in the span (or array). In other words, each arm (or disk) of the span may include the same WJ metadata block in order to tolerate disk failures of redundant LDs.

[0045] For example, in a layout of LDs on all participating arms (or disks) across a RAID 5 LD configured with 2 spans (each span includes 3 arms (or disks)), each arm of the first span may be divided into portions of a data or parity stripe, a write log data stripe, a WJ metadata block, and / or a DDF block. The data or parity stripe in each arm may include (N+1) data or parity stripes (N is a positive integer), for example, data or parity stripe 0 to data or parity stripe N. The WJ data stripe in each arm may include (M+1) WJ data stripes (M is a positive integer), for example, WJ data stripe 0 to WJ data stripe M. Each WJ data stripe may contain write log data corresponding to the data or parity stripe or data row of the span of the arm. The WJ metadata block in each arm may include (M+1) WJ metadata blocks, for example, WJ metadata block 0 to WJ metadata block M. A WJ metadata block may be reserved for each of the WJ data stripes. The WJ metadata block may maintain, maintain or store metadata information of the write log data stored in the corresponding WJ data stripe. A WJ metadata block in one arm may be replicated on all other arms participating in the span. In other words, each arm of the span may contain the same WJ metadata block in order to tolerate disk failures of redundant LDs. The second span may have a layout identical to that of the first span.

[0046] In some embodiments, the WJ metadata block may provide metadata information for the corresponding WJ data stripe. The WJ metadata block and the WJ data stripe may be mapped one-to-one. For example, a WJ metadata block k (k is an integer such that 0≤k≤M) on a disk may maintain, maintain, contain, or store metadata information for the corresponding WJ data stripe k. Each metadata block may be in an open state (also referred to as each metadata block "open"), or in a closed state (also referred to as each metadata block "closed"). If there is an incomplete (e.g., yet to be completed) host I / O (e.g., write) on the data row corresponding to the WJ metadata block, then the WJ metadata block may be in an open state. If there is no incomplete host I / O on the data row corresponding to the WJ metadata block, then the WJ metadata block may be in a closed state.

[0047] In some embodiments, the WJ metadata block may include the following fields: (1) WJ metadata block number, (2) WJ index, (3) LD ID, (4) LD span, (5) user data stripe number, and / or (6) validity information about the data block stripes in the span in the data or parity stripes of the write log of all arms participating in the span (e.g., whether each LBA block is dirty or valid). In some embodiments, the validity information field may include a bitmap for each arm (e.g., three bitmaps if there are three arms in the span). The bitmap for a particular arm may include a number of bits corresponding to the number of LBAs in the data stripe portion of the particular arm. The bitmap may specify which LBAs on a particular arm have valid data or parity that needs to be written to the corresponding arm (or disk) as part of the write log replay. In some embodiments, the bitmap may set the bits corresponding to LBAs with valid data or parity to a particular value (e.g., a value of "1") and set the bits corresponding to LBAs with dirty data or parity to another value (e.g., a value of "0"). For example, a WJ metadata block in an open state (for writing to a log) may include a logical disk (LD) identifier in the LD ID field, an LD span number in the LD span field, and an LD user data stripe number in the user data stripe number field in which the log is written to be open. If the span includes three arms (arm 0, arm 1, arm 2), then the WJ metadata block in an open state may include a bitmap for arm 0 (e.g., arm [0]), a bitmap for arm 1 (e.g., arm [1]), and a bitmap for arm 2 (e.g., arm [2]). On the other hand, a WJ metadata block in a closed state (for writing to a log) may include a specific value in the LD ID field (e.g., "invalid LD ID"), and include values ​​indicating "unavailable" or "empty" in the fields of the LD span, user data stripe number, and bitmap. The contents in the WJ metadata block may be replicated or mirrored on all arms in the span so that the log remains intact in the event of any arm failure at the LD span level. For example, a WJ metadata block on arm 0 may also be copied to arm 1 and arm 2, and the contents of a WJ data stripe in one arm may be different from the contents of a WJ data stripe in another arm. WJ metadata block 0 in arm 0 is the same as WJ metadata block 0 in arm 1 and WJ metadata block 0 in arm 2.

[0048] In one method, the write log system can use a stripe update process to update the user data stripe (e.g., user data blocks across all spans). At the first step of the stripe update process, the system can read the old data of the stripe (in the case of read-modify-write) or the peer data of the stripe (in the case of read-peer), and calculate the parity data of the user data stripe in the LD span. At the second step of the stripe update process, the system can find and select a free WJ metadata block for the LD span. At the third step of the stripe update process, the system can issue one or more write commands for writing the new data and the calculated parity data to the WJ data stripe corresponding to the WJ metadata block selected in the second step. The system can wait for these write commands to complete. At the fourth step of the stripe update process, the system can update or write the WJ metadata block (as selected in the second step) with the metadata information on the write log of the new data. The system can wait for this write (to the WJ metadata block) to complete. When completed, the system can consider or indicate that the write log is in an open state. At the fifth step of the stripe update process, the system may issue one or more write commands for writing the new data and the calculated parity data to the user data stripe in the LD span (associated with the user data stripe). At the sixth step of the stripe update process, the system may update the WJ metadata block with "INVALID LD ID" to change the write log to a closed state.

[0049] In one method, for example, in the case where a RAID controller crashes or the LD state is changed to offline because a disk or housing is removed between stripe writes, the user data stripe may remain in an inconsistent state. In this case, the write log system can use an open write log to perform controller recovery or LD recovery to make such user data stripes consistent. The system can use a log recovery process to scan the open write log and perform recovery using the open write log. At the first step of the log recovery process, for each LD span, the system can read the WJ metadata block. At the second step of the log recovery process, the system can find the WJ metadata block with the write log in the open state. At the third step of the log recovery process, for each arm associated with the open log, the system can use the metadata information contained in the WJ metadata block to generate a disk write command to (1) read a valid arm LBA from the WJ data stripe, and (2) write the read LBA to the data stripe present in the metadata information. At the fourth step of the log recovery process, the system can update the WJ metadata block with "INVALID LDID" to change the write log to a closed state.

[0050] In one approach, in situations where disk failure or media corruption may result in loss of write log information, the write log system may perform log error handling to safely guard against such problems. In some embodiments, the system may replicate WJ metadata blocks across all arms of a span so that as long as there are enough arms (or disks) available to keep the LD online or in a degraded state, the write log information may be available. In the event of a media error in a WJ metadata block in one arm, the system may use the same WJ metadata block from another arm since the WJ metadata block is replicated across all arms in the span.

[0051] The embodiments of the present disclosure have at least the following advantages and benefits: First, the embodiments of the present disclosure can provide a useful technique for writing logs that may not require a battery backup solution by maintaining, maintaining or storing write log information on the same set of arms (or disks) on which LDs are created.

[0052] Second, embodiments in the present disclosure may provide useful techniques for write logging that may not require DRAM-based cache memory by keeping, maintaining, or storing write log information on an ARM (or disk) that is not limited in size compared to DRAM.

[0053] Third, embodiments in the present disclosure may provide useful techniques for write logs that may preserve, maintain, or store both the data on the disk (or arm) and the write log metadata for the data to make user data stripes consistent across various types of failures (e.g., controller power failure, disk failure, disk failure followed by controller power failure).

[0054] Fourth, embodiments in the present disclosure may provide a useful technique for write logging that may not keep write log information in a RAID controller and may still repair parity in the event of a controller failure.

[0055] Fifth, embodiments of the present disclosure may provide useful techniques for writing logs that may not significantly increase the number of I / Os to the disk to maintain the log information. Therefore, the writing log techniques may perform better in a solid state drive (SSD) than in a hard disk drive (HDD).

[0056] Figure 2 2 is a schematic block diagram of a system 200 for performing on-disk write logging according to an embodiment. The system 200 may include a RAID controller 240 and a RAID 250. Each of the RAID controller 240 and the RAID 250 may, but need not, have a Figure 1B250. Among other potential differences, the RAID controller 240 and the RAID 250 need not have all of the components discussed with respect to the computing system. In the RAID 250, the disks (or arms of the array) may be divided into portions of data or parity stripes 210, write log (WJ) data stripes 220, WJ metadata blocks, and / or DDF blocks 240. In some embodiments, data may be located in the order of data or parity stripes, WJ data stripes, WJ metadata blocks, and DDF blocks using an addressing scheme (e.g., LBA), but in other embodiments, data may be located in another order (e.g., in the order of data or parity stripes, WJ metadata blocks, WJ data stripes, and DDF blocks). In some embodiments, the disk LBAs may be grouped into stripes based on the LD stripe size. For example, if the LD has a 64KB stripe size on a physical device (PD) with 4KB sized LBAs, 16 consecutive LBAs may be grouped in a single stripe. For example, referring to Figure 2 , data or parity stripe 0 may be stored at the first LBA 250, and the last block of the DDF block may be stored at the last LBA 260. Data or parity stripe 210 may include (N+1) data or parity stripes (N is a positive integer), for example, data or parity stripe 0 to data or parity stripe N. WJ data stripe may include (M+1) WJ data stripes (M is a positive integer), for example, WJ data stripe 0 to WJ data stripe M. WJ metadata block may include (M+1) WJ metadata blocks, for example, WJ metadata block 0 to WJ metadata block M.

[0057] refer to Figure 2 , each data or parity stripe 0 to N may contain user data or parity data. Each WJ data stripe 0 to M may contain write log data corresponding to the data or parity stripe of the arm to maintain the write log data. For example, WJ data stripe 0 may contain write log data corresponding to data or parity stripe 2. In some embodiments, the write log data contained in the WJ data stripe may include the same content as the corresponding data or parity stripe. The number of stripes (e.g., the number M) reserved for the WJ data stripe can be determined based on the number of incomplete data row writes on the LD. In some embodiments, the number of stripes reserved for the WJ data stripe can be derived from the number of incomplete host I / Os written through the LD or the number of incomplete row refreshes written back to the LD.

[0058] refer to Figure 2, a WJ metadata block (e.g., WJ metadata blocks 0 to M) may be retained for each of the WJ data stripes 0 to M. The WJ metadata block may maintain, maintain, or store metadata information of the write log data stored in the corresponding WJ data stripe. For example, WJ metadata block k (0≤k≤M) may maintain, maintain, or store metadata information of the write log data stored in WJ data stripe k. Each WJ metadata block may include (1) an LD number, (2) mapping information of the WJ data stripe to the corresponding data or parity stripe (in the span), and / or (3) validity information about blocks in the data or parity stripes of the write logs of all disks (or arms) participating in the span (e.g., whether each LBA block is dirty or valid). Reference will be made to the following. Figure 4A and 4B Describes the details of the WJ metadata layout.

[0059] Figure 3 3 is a schematic block diagram of a system for performing on-disk write logs according to an embodiment. System 300 may include a RAID controller 340 and a RAID 350. Each of RAID controller 340 and RAID 350 may have Figure 1B RAID controllers and RAID may not necessarily be the same Figure 1B The computing system matches in may not necessarily contain information about Figure 1B All components described in the computing system in Figure 1B 1 and 2. The RAID 150 may be a RAID 5 logical device (LD) having two spans (Span 0 (301) and Span 1 (302)), each of which includes three arms (Arm 0, Arm 1, Arm 2), so that a single span may form a LD. Figure 3 The layout of the LDs across all participating arms (or disks) (ARM0, ARM1, ARM2) in span 301 is shown. Span 302 may have the same or similar layout as that of span 301.

[0060] refer to Figure 3, each arm of span 0 (arm 0, arm 1, arm 2) may be divided into data or parity stripes 310, 311, 312, write log data stripes 320, 321, 322, WJ metadata blocks 330, 331, 332, and / or portions of DDF blocks 340, 341, 342. The data or parity stripes in each arm may include (N+1) data or parity stripes (N is a positive integer), for example, data or parity stripe 0 to data or parity stripe N. The WJ data stripes in each arm may include (M+1) WJ data stripes (M is a positive integer), for example, WJ data stripe 0 to WJ data stripe M. Each WJ data stripe may contain write log data corresponding to the data or parity stripe or data rows of the span of the arm. For example, referring to Figure 3 , WJ data stripe 0 in arm 0, WJ data stripe 0 in arm 1, and WJ data stripe 0 in arm 2 may contain write log data corresponding to parity stripe 2 in arm 0, data stripe 2 in arm 1, and data stripe 2 in arm 2, respectively, which may form row 2 (or data row) in span 301. The WJ metadata block in each arm (e.g., arm 0, arm 1, arm 2) may include (M+1) WJ metadata blocks, e.g., WJ metadata block 0 to WJ metadata block M. WJ metadata blocks may be reserved for each of the WJ data stripes. WJ metadata blocks and WJ data stripes may be mapped one-to-one. For example, WJ metadata block k (0≤k≤M) may maintain, maintain, or store metadata information of write log data stored in WJ data stripe k. WJ metadata blocks in one arm (e.g., arm 0 in span 301) may be copied to all other arms participating in the span (e.g., arm 1 and arm 2 in span 301). In other words, each arm of the span may contain the same WJ metadata block in order to tolerate disk failures of redundant LDs. The number of stripes (or the number of WJ metadata blocks) reserved for WJ data stripes may be determined based on the number of outstanding data row writes on the LDs. In some embodiments, the number of stripes reserved for WJ data stripes may be derived from the number of outstanding host I / Os (input / outputs) for write-through LDs or the number of outstanding row refreshes for write-back LDs.

[0061] refer to Figure 3, the WJ metadata block in each arm (e.g., arm 0, arm 1, arm 2) in span 301 may include (1) LD number, (2) mapping information of the WJ data stripe to the corresponding data or parity stripe (in span 301), and / or (3) validity information about blocks in the data or parity stripe of the write log of all arms participating in span 301 (e.g., whether each LBA block is dirty or valid). Each WJ metadata block may be in an open state or in a closed state. If there is an incomplete (e.g., yet to be completed) host I / O (e.g., write) on the data row corresponding to the WJ metadata block, then the WJ metadata block may be in an open state. If there is no incomplete host I / O on the data row corresponding to the WJ metadata block, then the WJ metadata block may be in a closed state. The following will refer to Figure 4A and 4B Describes the details of the WJ metadata layout.

[0062] Figure 4A and Figure 4B is a schematic block diagram of a layout 400 of WJ metadata blocks 0 to M (410-0, ..., 410-M; collectively 410) for write logging according to an embodiment. The WJ metadata block may include the following fields: (1) WJ metadata block number 420, (2) WJ index 430, (3) LD ID 440, (4) LD span 450, (5) user data stripe number 460, and / or (6) information about all arms participating in the span (e.g., Figure 3 The data or parity stripe written to the log (for example, Figure 3 Validity information 405 of the data block stripes in the spans (e.g., whether each LBA block is dirty or valid) in the data or parity stripes 0 to N in the WJ metadata block. In some embodiments, the WJ metadata block number field 420 of the WJ metadata block may identify the WJ metadata block (e.g., the LBA address). The LD ID field 440 may identify the LD to which the WJ metadata block belongs. The LD span field 450 may identify the span to which the WJ metadata block belongs (e.g., Figure 3 The WJ index 430 may identify the WJ data stripe corresponding to the WJ metadata block in the corresponding span. Figure 3 , WJ metadata block 410-1 may have a WJ index "1" corresponding to WJ data stripe 1 in span 301 (e.g., WJ data stripe 1 in arm 0, WJ data stripe 1 in arm 1, and WJ data stripe 1 in arm 2). User data stripe number field 460 may identify data or parity corresponding to a WJ metadata block in the corresponding span. For example, referring to Figure 3, WJ metadata block 410-1 may have a user data stripe number "2" corresponding to data or parity stripe 2 in span 301 (e.g., parity stripe 2 in arm 0, data stripe 2 in arm 1, data stripe 2 in arm 2).

[0063] refer to Figure 4A and Figure 4B , the validity information field 405 may include a bitmap for each arm (e.g., three bitmap fields arm[0] 470, arm[0] 480, and arm[2] 490 corresponding to arm 0, arm 1, and arm 2). The bitmap for a particular arm may include a plurality of bits (e.g., 16 bits) corresponding to the number of LBAs in the data stripe identified by the user data stripe number 460 in the particular arm (e.g., 16 4KB LBAs forming a 64KB data stripe). The bitmap may specify which LBAs of the data stripe in the particular arm have valid data or parity that need to be written to the corresponding arm as part of a write log replay. In some embodiments, the bitmap may set bits corresponding to LBAs with valid data or parity to a particular value (e.g., a value of "1") and bits corresponding to LBAs with dirty data or parity to another value (e.g., a value of "0"). For example, the WJ metadata block 410-1 may include bits for span 0 (e.g., Figure 3 301 in FIG. 302 ), arm 0 bitmap arm[0] 470-1 for arm 1 of span 0, and arm[2] 490-1 for arm 2 of span 0. Bitmap 470-1 may indicate span 0 (see Figure 3 ) has valid data, and the other LBAs of data stripe 1 in arm 0 of span 0 have dirty data. Bitmap 480-1 may indicate span 0 (see Figure 3 ) have valid parity, and the other LBAs of parity stripe 1 in arm 1 of span 0 have dirty data. Bitmap 490-1 may indicate span 0 (see Figure 3 ) have valid parity, and the other LBAs of data stripe 1 in arm 2 of span 0 have dirty data.

[0064] refer to Figure 4B, the WJ metadata block 410-M may include a bitmap arm[0] 470-M for arm 0 of span 0, a bitmap arm[1] 480-M for arm 1 of span 0, and a bitmap arm[2] 490-M for arm 2 of span 0. The bitmap 470-M may indicate that all LBAs of the parity stripe 100 in arm 0 of span 0 have valid data, and the LBAs of the parity stripe 100 in arm 0 of span 0 have no dirty data. The bitmap 480-M may indicate that all LBAs of the data stripe 100 in arm 1 of span 0 have valid data, and the LBAs of the data stripe 100 in arm 1 of span 0 have no dirty data. The bitmap 490-M may indicate that all LBAs of the data stripe 100 in arm 2 of span 0 have valid data, and the LBAs of the data stripe 100 in arm 2 of span 0 have no dirty data.

[0065] refer to Figure 4A and Figure 4B , the WJ metadata block in the open state (e.g., WJ metadata block 410-0) may include an LD identifier (e.g., 0) in the LDID field 440, an LD span number (e.g., 0) in the LD span field 450, and an LD user data stripe number (e.g., 0) in which the write log is in the open state in the user data stripe number field 460. If the span includes three arms (arm 0, arm 1, arm 2), the WJ metadata block in the open state (e.g., WJ metadata block 410-0) may include a bitmap for arm 0 (e.g., bitmap 470-0), a bitmap for arm 1 (e.g., bitmap 480-0), and a bitmap for arm 2 (e.g., bitmap 490-0). On the other hand, a WJ metadata block in a closed state (e.g., WJ metadata block 410-2) may include a specific value (e.g., "invalid LD ID") in the LD ID field 430, and a value indicating "unavailable" or "empty" in the fields of the LD span 440, the user data stripe number 450, and the bitmaps 460, 470, 480. The content in the WJ metadata block may be replicated or mirrored on all arms in the span (e.g., arm 0, arm 1, arm 2) so that the log remains intact in the event of any arm failure at the LD span level. For example, a WJ metadata block on arm 0 (e.g., WJ metadata block 330) may also be replicated to arm 1 (e.g., WJ metadata block 331) and arm 2 (e.g., WJ metadata block 332), and the content of a WJ data stripe (e.g., data or parity stripe 310) in one arm may be different from the content of a WJ data stripe (e.g., data or parity stripe 311, data or parity stripe 312) in another arm. WJ metadata block 0 in arm 0 may be identical to WJ metadata block 0 in arm 1 and WJ metadata block 0 in arm 2.

[0066] Figure 55 is a flow chart showing a process 500 for writing new data on a disk according to an embodiment. In some embodiments, a write log system (e.g., write log system 200 or 300) may use a stripe update process to update a user data stripe. In some embodiments, a user data stripe may be a user data block across all spans (e.g., Figure 3 The user data stripe 0 in the data or parity stripe 0 in arms 0 to 2 of span 0 and the data or parity stripe 0 in arms 0 to 2 of span 1).

[0067] At step 502, the system may read the old data of the stripe (in the case of read-modify-write) or the peer data of the stripe (in the case of read-peer) and calculate the LD span (e.g., Figure 3 At step 504, the system may find and select a free WJ metadata block (eg, WJ metadata block 0) for the LD span.

[0068] At step 506, the system may issue one or more write commands for writing the new data (e.g., new data for data stripe 0 in arm 0) and the calculated parity data (e.g., parity data for parity stripe 0 in arm 2) to the WJ data stripes (e.g., WJ data stripe 0 in arm 0 and WJ data stripe 0 in arm 2) corresponding to the WJ metadata block (e.g., WJ metadata block 0) selected in step 502. The system may wait for these write commands to complete.

[0069] At step 508, the system may use metadata information (e.g., Figure 4A 4, such as WJ metadata block number 420, WJ index 430, LD ID 440, LD span 450, user data stripe number 460, validity information 405) to update or write the WJ metadata block (e.g., WJ metadata block 0 selected in step 502) to the write log for new data. The system may wait for this write (to WJ metadata block 0) to complete. Upon completion, the system may consider or indicate that the write log is in an open state.

[0070] At step 510, the system may issue one or more write commands for writing the new data and the calculated parity data to the user data stripe (associated with the user data stripe) in the LD span. For example, the system may issue one or more write commands for writing the new data and the calculated parity data to data stripe 0 in arm 0 and parity stripe 0 in arm 2, respectively. At step 512, (upon successful completion of the one or more write commands), the system may update the WJ metadata block (e.g., WJ metadata block 0) with "INVALIDLD ID" to change the write log to a closed state.

[0071] Figure 6 Flowchart showing the process for log recovery according to an embodiment. For example, when a RAID controller crashes or an LD state is changed to offline because a disk or housing is removed between stripe writes, the user data stripe may remain in an inconsistent state. In this case, a write log system (e.g., a write log system 200 or 300) may use an open write log (e.g., a WJ data stripe or WJ metadata block in an open state) to perform controller recovery or LD recovery to make such user data stripes consistent. The system may use a log recovery process to scan an open write log (e.g., a WJ metadata block with an LD ID field 440 of a valid LD ID) and perform recovery using an open write log.

[0072] At step 602, for each LD span, the system can read a WJ metadata block (e.g., WJ metadata block). At step 604, the system can find a WJ metadata block with a write log in an open state (e.g., WJ metadata block 0 whose LD ID field 440 is set to a valid LD ID, such as Figure 4A ).

[0073] At step 606, for each arm associated with the open log (e.g., arm 0, arm 1, arm 2 associated with WJ metadata block 0), the system can use the metadata information contained in the WJ metadata block to generate a disk write command to (1) read a valid arm LBA from the WJ data stripe, and (2) write the read LBA to the data stripe present in the metadata information. For example, the system can use bitmap arm [0] 470-0 to generate a disk write command to (1) read the first through fourth LBAs from WJ data stripe 0 in arm 0, and (2) write the read LBAs to data stripe 0 in arm 0. The system can also use bitmap arm [1] 480-0 to generate a disk write command to (1) read the sixth through tenth LBAs from WJ data stripe 0 in arm 1, and (2) write the read LBAs to data stripe 0 in arm 1. The system can also use bitmap arm [2] 490-0 to generate disk write commands to (1) read the first to fourth LBAs and the sixth to tenth LBAs from WJ data stripe 0 in arm 2, and (2) write the read LBAs to parity stripe 0 in arm 2.

[0074] At step 608, the system may update the WJ metadata block (e.g., WJ metadata block 0) with "INVALID LD ID" to change the write log to a closed state. In some embodiments, in situations where a disk failure or media damage may result in the loss of write log information, the write log system may perform log error handling to safely guard against such problems. For example, the system may replicate the WJ metadata block on all arms of a span (e.g., replicate WJ metadata block 0 on arm 0, arm 1, and arm 2 of span 0) so that as long as there are enough arms (or disks) available to keep the LD online or in a degraded state, the write log information may be available. In the event of a media error in a WJ metadata block in one arm (e.g., arm 0), the system may use the same WJ metadata block from another arm (e.g., arm 2) because the WJ metadata block is replicated to all arms in the span.

[0075] Figure 7 700 is a flow chart showing a process 700 for writing a log on a disk according to an embodiment. In some embodiments, the process 700 is performed by one or more processors (e.g., one or more processors of the RAID controller 240, 340, or one or more processors of the RAID 250, 350). In other embodiments, the process 700 is performed by other entities. In some embodiments, the process 700 includes more than Figure 7 There may be more, fewer, or different steps than those shown.

[0076] At step 702, one or more processors may receive a write operation (eg, a write operation command from the host 120) to write a data block (eg, corresponding to Figure 3In some embodiments, the write operation may be an operation (or one or more commands) to write data to a storage device, or an operation to write data to any device suitable for storing computer-readable data. The one or more storage devices may retain one or more data stripes (e.g., WJ data stripes 320, 321, 322) and one or more metadata blocks (e.g., WJ metadata blocks 330, 331, 332) to store data written to the log.

[0077] At step 704, the one or more processors may identify a first storage device (eg, Figure 3 The first data stripe of the data block in arm 0 or arm 2) (for example, Figure 3 At step 706, the one or more processors may write a copy of the first data stripe to a data stripe in one or more data stripes (e.g., WJ data stripe 0) retained on the first storage device (e.g., arm 0 or arm 2). At step 708, the one or more processors may write metadata associated with the data block to a metadata block (e.g., WJ metadata block 0) in one or more metadata blocks retained on the first storage device (e.g., arm 0 or arm 2).

[0078] At step 710, one or more processors may perform a write operation to store a block of data (eg, corresponding to a data block) across one or more storage devices (eg, arm 0, arm 1, arm 2 in span 301). Figure 3 In some embodiments, the one or more processors may write a first data stripe of a data block at a location (e.g., location 310 or location 312) of the first storage device when performing a write operation, the location being different from a location (e.g., location 320 or location 322) of a data stripe in one or more data stripes retained on the first storage device. In some embodiments, metadata associated with the data block may include location information of the data block (e.g., user data stripe number 460). In some embodiments, the first data stripe of the data block may include one of parity data (e.g., parity stripe 0) or non-parity data (e.g., data stripe 0).

[0079] In some embodiments, the one or more processors may identify a second data stripe (e.g., data stripe 0 in arm 1) of a data block to be written to a second storage device (e.g., arm 1) in the one or more storage devices. The one or more processors may write a copy of the second data stripe to a data stripe (e.g., WJ data stripe 0 in arm 1) of the one or more data stripes retained on the second storage device. The one or more processors may write metadata associated with the data block to a metadata block in one or more metadata blocks (e.g., WJ metadata block 0) retained on the second storage device (e.g., arm 1). When performing a write operation, the one or more processors may write the second data stripe of the data block at a location (e.g., location 311) of the second storage device that is different from a location (e.g., location 321) of the data stripe in the one or more data stripes retained on the second storage device. The metadata may include first mapping data (e.g., arm[0]) identifying which portion of a first storage device (e.g., arm 0) is to be modified due to a write operation, and second mapping data (e.g., arm[1]) identifying which portion of a second storage device (e.g., arm 1) is to be modified due to a write operation. Each of the first mapping data and the second mapping data may be a bitmap (e.g., bitmaps 470-0, 480-0).

[0080] In some embodiments, one or more processors may detect an inconsistent state of one or more storage devices. In response to the detection, the one or more processors may determine whether the metadata block is open or closed. For example, if there is an unfinished (e.g., yet to be completed) host I / O operation (e.g., write) on the data row corresponding to the metadata block, then the metadata block (e.g., WJ metadata block 410-0) may be in an open state. If there is no unfinished host I / O operation on the data row corresponding to the metadata block, then the metadata block (e.g., WJ metadata block 410-2) may be in a closed state. In response to determining that the metadata block is open, the one or more processors may read the metadata block (e.g., WJ metadata block 410-0) to obtain the location information (e.g., "0" from the WJ index field 430) of the copy of the first data stripe (e.g., WJ data stripe 0) and the copy of the second data stripe (e.g., WJ data stripe 1) stored in the first storage device (e.g., arm 0) and the second storage device (e.g., arm 1), respectively. The one or more processors may write a copy of the first data stripe to the first storage device and a copy of the second data stripe to the second storage device based on the location information. In response to writing the copy of the first data stripe and the copy of the second data stripe, the one or more processors may indicate the metadata block as closed (e.g., setting the LD ID field 440 to "Invalid LD ID").

[0081] The term "coupled" and its variants include two components directly or indirectly joined to each other. The term "electrically coupled" and its variants include two components directly or indirectly joined to each other through a conductive material (e.g., a metal or copper trace). Such joining (for both the terms "coupled" and "electrically coupled") may be static (e.g., permanent or fixed) or movable (e.g., removable or releasable). Such joining (for both the terms "coupled" and "electrically coupled") may be achieved by two components directly coupled to each other, wherein the two components are coupled to each other using separate intervening components and any additional intermediate components that are coupled to each other, or wherein the two components are coupled to each other using an intervening component that is integrally formed with one of the two components as a single, unitary body. If "coupled" or its variants are modified by additional terms (e.g., directly coupled), the general definition of "coupled" provided above is modified by the colloquial language meaning of the additional terms (e.g., "directly coupled" means that the two components are joined without any separate intervening components), resulting in a narrower definition than the general definition of "coupled" provided above. Such coupling may be mechanical, electrical, or fluidic.

[0082] The foregoing summarizes the features of several embodiments so that those skilled in the art can better understand aspects of the present disclosure. Those skilled in the art will appreciate that they can easily use the present disclosure as a basis for designing or modifying other processes and structures to achieve the same purposes and / or achieve the same advantages of the embodiments introduced herein. Those skilled in the art will also appreciate that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and modifications may be made herein without departing from the spirit and scope of the present disclosure.

[0083] It should be noted that certain paragraphs of the present disclosure may refer to terms such as "first" and "second" in conjunction with stripes, data blocks, data rows, and devices for the purpose of identifying or distinguishing one from another or other. These terms are not intended to relate entities (e.g., first device and second device) only in time or according to a sequence, but in some cases, these entities may include such relationships. These terms also do not limit the number of possible entities that can operate in a system or environment. It should be understood that the system described above may provide multiple of any one or each of those components, and these components may be provided on a stand-alone machine, or in some embodiments, on multiple machines in a distributed system. In addition, the above-described systems and methods may be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture (e.g., floppy disks, hard disks, CD-ROMs, flash memory cards, PROMs, RAMs, ROMs, or tapes). The program may be implemented in any programming language (e.g., LISP, PERL, C, C++, C#) or in any byte code language (e.g., JAVA). The software program or executable instructions may be stored as object code on or in one or more articles of manufacture.

[0084] Although the foregoing written description of the methods and systems enables one of ordinary skill in the art to make and use embodiments thereof, one of ordinary skill in the art will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiments, methods, and examples herein. Therefore, the methods and systems should not be limited to the embodiments, methods, and examples described above, but should be limited to all embodiments and methods within the scope and spirit of the present disclosure.

Claims

1. A system comprising: One or more processors configured to: receiving a write operation to write a data block to a logical device established using one or more storage devices that retain one or more data stripes and one or more metadata blocks to store data of one or more write logs, identifying a first data stripe of the data blocks to be written to a first storage device of the one or more storage devices, writing a copy of the first data stripe to a data stripe of the one or more data stripes retained on the first storage device, writing metadata associated with the data block to a metadata block in the one or more metadata blocks retained on the first storage device, and The write operation is performed to store the block of data across the one or more storage devices.

2. The system of claim 1 , wherein when performing the write operation, the one or more processors are configured to: The first data stripe of the data block is written at a location on the first storage device that is different from a location of the data stripe among the one or more data stripes retained on the first storage device. 3 . The system of claim 1 , wherein the metadata associated with the data block includes location information of the data block. 4 . The system of claim 1 , wherein the first data stripe of the data block includes at least one of parity data or non-parity data.

5. The system of claim 1, wherein the one or more processors are configured to identifying a second data stripe of the data blocks to be written to a second storage device of the one or more storage devices, writing a copy of the second data stripe to a data stripe of the one or more data stripes retained on the second storage device, and The metadata associated with the data block is written to a metadata block among the one or more metadata blocks retained on the second storage device.

6. The system of claim 5, wherein in performing the write operation, the one or more processors are configured to: The second data stripe of the data block is written at a location on the second storage device that is different from a location of the data stripe in the one or more data stripes retained on the second storage device.

7. The system of claim 5, wherein the metadata comprises: first mapping data identifying which portion of the first storage device is to be modified as a result of the write operation; and Second mapping data identifying which portion of the second storage device is to be modified as a result of the write operation.

8. The system of claim 7, wherein each of the first mapping data and the second mapping data is a bitmap.

9. The system of claim 5, wherein the one or more processors are configured to: detecting an inconsistent state of the one or more storage devices; In response to the detecting, determining whether the metadata block is turned on or off, In response to determining that the metadata block is open, reading the metadata block to obtain location information of the copy of the first data stripe and the copy of the second data stripe stored in the first storage device and the second storage device, respectively; and Based on the location information, the copy of the first data stripe is written to the first storage device and the copy of the second data stripe is written to the second storage device.

10. The system of claim 9, wherein the one or more processors are configured to: In response to writing the copy of the first data stripe and the copy of the second data stripe, indicating that the metadata block is closed.

11. A method comprising: receiving, by one or more processors, a write operation to write a data block to a logical device established using one or more storage devices, the one or more storage devices retaining one or more data stripes and one or more metadata blocks to store data of one or more write logs; identifying, by the one or more processors, a first data stripe of the data blocks to be written to a first storage device of the one or more storage devices; writing, by the one or more processors, a copy of the first data stripe to a data stripe of the one or more data stripes retained on the first storage device; writing, by the one or more processors, metadata associated with the data block to a metadata block among the one or more metadata blocks retained on the first storage device; and The write operation is performed by the one or more processors to store the block of data across the one or more storage devices.

12. The method of claim 11, wherein performing the write operation comprises: The first data stripe of the data block is written at a location on the first storage device that is different from a location of the data stripe among the one or more data stripes retained on the first storage device. The method according to claim 11 , wherein the metadata associated with the data block includes location information of the data block.

14. The method of claim 11, wherein the first data stripe of the data block includes at least one of parity data or non-parity data.

15. The method according to claim 11, further comprising: identifying a second data stripe of the data blocks to be written to a second storage device of the one or more storage devices; writing a copy of the second data stripe to a data stripe among the one or more data stripes retained on the second storage device; and The metadata associated with the data block is written to a metadata block among the one or more metadata blocks retained on the second storage device.

16. The method of claim 15, wherein performing the write operation comprises: The second data stripe of the data block is written at a location on the second storage device that is different from a location of the data stripe in the one or more data stripes retained on the second storage device.

17. The method of claim 15, wherein the metadata comprises: first mapping data identifying which portion of the first storage device is to be modified as a result of the write operation; and Second mapping data identifying which portion of the second storage device is to be modified as a result of the write operation.

18. The method of claim 17, wherein each of the first mapping data and the second mapping data is a bitmap.

19. The method of claim 15, further comprising: detecting an inconsistent state of the one or more storage devices; In response to the detecting, determining whether the metadata block is turned on or off, In response to determining that the metadata block is open, reading the metadata block to obtain location information of the copy of the first data stripe and the copy of the second data stripe stored in the first storage device and the second storage device, respectively; and Based on the location information, the copy of the first data stripe is written to the first storage device and the copy of the second data stripe is written to the second storage device.

20. The method of claim 19, further comprising: In response to writing the copy of the first data stripe and the copy of the second data stripe, indicating that the metadata block is closed.

Images