Fail-safe redundancy in aggregated and virtualized solid-state drives

Abstract

The present application relates to fault protection redundancy in aggregated and virtualized solid-state drives. A solid-state drive has at least one component solid-state drive, a spare solid-state drive, and a drive aggregator. The drive aggregator has at least one host interface, at least one drive interface connected to the at least one component solid-state drive, and an interface connected to the spare solid-state drive. The drive aggregator is configured to maintain a copy of a data set stored in the component solid-state drive in the spare solid-state drive. In response to a failure of the component solid-state drive, the drive aggregator is configured to replace the function of the component solid-state drive relative to the data set with the corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

Description

Technical Field

[0001] At least some embodiments disclosed herein relate generally to memory systems, and more particularly, but not limited to, aggregation and virtualization of solid-state drives with fail-safe redundancy. Background Art

[0002] The memory subsystem may be a storage system, such as a solid state drive (SSD) or a hard disk drive (HDD). The memory subsystem may be a memory module, such as a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), or a non-volatile dual in-line memory module (NVDIMM). The memory subsystem may include one or more memory components that store data. The memory components may be, for example, non-volatile memory components and volatile memory components. Examples of memory components include memory integrated circuits. Some memory integrated circuits are volatile and require power to maintain the stored data. Some memory integrated circuits are non-volatile and can maintain the stored data even when not powered. Examples of non-volatile memory include flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electronically erasable programmable read-only memory (EEPROM) memory, etc. Examples of volatile memory include dynamic random access memory (DRAM) and static random access memory (SRAM).In general, a host system may utilize a memory subsystem to store data at and retrieve data from memory components.

[0003] For example, a computer may include a host system and one or more memory subsystems attached to the host system. The host system may have a central processing unit (CPU) that communicates with the one or more memory subsystems to store and / or retrieve data and instructions. Instructions for the computer may include an operating system, a device driver, and an application program. The operating system manages resources in the computer and provides common services for application programs such as memory allocation and time sharing of resources. The device driver operates or controls a specific type of device in the computer; and the operating system uses the device driver to provide resources and / or services provided by the device of that type. The central processing unit (CPU) of the computer system may run the operating system and the device driver to provide services and / or resources to the application program. The central processing unit (CPU) may run an application program that uses the services and / or resources. For example, an application program that implements a type of application of the computer system may instruct the central processing unit (CPU) to store data in a memory component of the memory subsystem and retrieve data from the memory component. Summary of the invention

[0004] In one aspect, the present application provides a solid-state drive, comprising: at least one component solid-state drive; a spare solid-state drive; and a drive aggregator, the drive aggregator having: at least one host interface; at least one drive interface connected to the at least one component solid-state drive; and an interface connected to the spare solid-state drive; wherein the drive aggregator is configured to maintain a copy of a data set stored in the component solid-state drive in the spare solid-state drive; and wherein in response to a failure of the component solid-state drive, the drive aggregator is configured to replace a function of the component solid-state drive relative to the data set with a corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

[0005] In another aspect, the present application further provides a method, which includes: providing a solid-state drive having multiple component solid-state drives, a spare solid-state drive, and a drive aggregator; receiving a command to operate a memory unit identified by a logical address in the drive aggregator via at least one host interface; implementing the command by the drive aggregator by transmitting the command to the component solid-state drive; maintaining a copy of a data set stored in a first component solid-state drive among the multiple component solid-state drives in the spare solid-state drive by the drive aggregator; and in response to a failure of the first component solid-state drive, replacing a function of the first component solid-state drive relative to the data set with a corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

[0006] In yet another aspect, the present application provides a drive aggregator comprising: at least one host interface configured to receive commands from at least one host system; a plurality of drive interfaces configured to connect to a plurality of component solid-state drives; an interface configured to connect to a spare solid-state drive; and translation logic coupled between the host interface, the plurality of drive interfaces, and the interface to the spare solid-state drive; wherein the translation logic is configured to maintain in the spare solid-state drive a copy of a data set stored in a first component solid-state drive of the plurality of component solid-state drives; and wherein in response to a failure of the first component solid-state drive, the translation is configured to replace a function of the first component solid-state drive relative to the data set with a corresponding function of the spare solid-state drive using the copy of the data set maintained in the spare solid-state drive. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

[0008] Figure 1 An example computing system having a memory subsystem according to some embodiments of the present disclosure is shown.

[0009] Figure 2 Shows a host system connected to a virtualized single solid-state drive having multiple component solid-state drives.

[0010] Figure 3 A drive aggregator according to one embodiment is shown.

[0011] Figure 4 A method implemented in a drive aggregator according to one embodiment is shown.

[0012] Figure 5 A method of distributing commands received in a virtualized solid-state drive to solid-state drives is presented.

[0013] Figure 6 Shows multiple host systems connected to a virtualized single solid-state drive having multiple component solid-state drives.

[0014] Figure 7 A drive aggregator having multiple host interfaces is shown according to one embodiment.

[0015] Figure 8 A host system is shown connected to a virtualized single solid-state drive via multiple parallel and / or redundant connections.

[0016] Fig. 9 A method of processing commands received in a virtualized solid-state drive via multiple host interfaces is presented.

[0017] Fig.10 Demonstrates a virtualized single solid-state drive with multiple component solid-state drives and a spare solid-state drive for fail-safe operation.

[0018] Fig.11 A drive aggregator configured to perform failover is shown according to one embodiment.

[0019] Fig.12 Demonstrates an example of changing the failover settings for failover and recovery.

[0020] Fig.13 Demonstrates method of failing over to spare solid-state drive. DETAILED DESCRIPTION

[0021] At least some aspects of the present disclosure are directed to techniques for aggregating multiple memory subsystems into a combined memory subsystem that acts as a single memory subsystem for a host system. In some embodiments, a single memory subsystem is configured with multiple host interfaces to serve multiple host systems, or serves one host system via multiple parallel and / or redundant connections. In some embodiments, the memory subsystem is configured with a fault protection mechanism.

[0022] Currently, solid-state drives (SSDs) may be provided in a single integrated circuit package. For example, a solid-state drive (SSD) may be packaged in a ball grid array (BGA) form factor. The BGA SSD has a controller embedded in the integrated circuit package to process commands from a host system, control operations to access data in a media unit or memory component embedded in the BGA SSD, and generate responses to commands from the host system. However, a single integrated circuit package and / or a BGA form factor may limit the storage capacity of the BGA SSD.

[0023] At least some aspects of the present disclosure address the above and other deficiencies via a drive aggregator that is configured to aggregate and virtualize multiple SSDs into a single SSD for a host system. Thus, multiple BGA SSDs can be used to construct one high-capacity SSD for a host system. The combined SSD can have a storage capacity that is not limited by a single integrated circuit package and / or BGA form factor.

[0024] Typically, a drive aggregator can be used to aggregate and virtualize multiple memory subsystems for a host system. One example of a memory subsystem is a storage device connected to a central processing unit (CPU) via a peripheral interconnect (e.g., an input / output bus, a storage area network). Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, and hard disk drives (HDDs). Another example of a memory subsystem is a memory module connected to a central processing unit (CPU) via a memory bus. Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), non-volatile dual in-line memory modules (NVDIMMs), and the like. In some embodiments, the memory subsystem is a hybrid memory / storage device subsystem that provides both memory functions and storage functions. In general, a host system can utilize a memory subsystem that includes one or more memory components. The host system can provide data to be stored at the memory subsystem and can request to retrieve data from the memory subsystem.

[0025] Figure 1 An example computing system 100 having a memory subsystem according to some embodiments of the present disclosure is shown. Figure 1 In FIG. 1 , a solid-state drive 101 is shown as an example of this memory subsystem. The aggregate solid-state drive 101 is constructed using multiple component solid-state drives 107 to 109. The drive aggregator 103 of the solid-state drive 101 virtualizes the entire combined capacity of the multiple component solid-state drives 107 to 109 into the capacity of the aggregate solid-state drive 101. The drive aggregator 103 shields the component solid-state drives 107 to 109 from the host system 111 so that the host system 111 can access the memory capacity of the multiple component solid-state drives 107 to 109 by addressing a single solid-state drive 101. In general, Figure 1 Each of the components in the solid-state drives 107 to 109 is another example of a memory subsystem.

[0026] In general, the memory subsystem may include media, such as a media unit / memory component. The media unit / memory component may be a volatile memory component, a non-volatile memory component, or a combination of these. Each of the media unit / memory components may perform operations of storing, recording, programming, writing, or submitting new data independently of the operations of other media units / memory components. Therefore, the media unit / memory component may be used in parallel to execute write commands. In some embodiments, the memory subsystem is a storage system. An example of a storage system is a solid-state drive (SSD). In other embodiments, the memory subsystem is a memory module. Examples of memory modules include DIMMs, NVDIMMs, and NVDIMM-Ps. In other embodiments, the memory subsystem is a hybrid memory / storage device subsystem. Typically, the computing system 100 may include a host system 111, which uses a memory subsystem (e.g., a solid-state drive 101) via a computer bus 117. For example, the host system 111 may write data to the memory subsystem and read data from the memory subsystem.

[0027] The host system 111 may be a computing device, such as a desktop computer, a laptop computer, a network server, a mobile device, or such a computing device including a memory and a processing device. The host system 111 may include or be coupled to a memory subsystem (e.g., a solid-state drive 101) via a computer bus 117, so that the host system 111 can read data from the memory subsystem or write data to the memory subsystem. The host system 111 may be coupled to the memory subsystem via a physical host interface. As used herein, "coupled" generally refers to a connection between components, which may be an indirect communication connection or a direct communication connection (e.g., without an intermediate component), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, etc. Examples of physical host interfaces include (but are not limited to) a serial advanced technology attachment (SATA) interface, a peripheral component interconnect high-speed (PCIe) interface, a universal serial bus (USB) interface, a fiber channel, a serial attached SCSI (SAS), a double data rate (DDR) memory bus, etc. The physical host interface can be used to transmit data between the host system 111 and the memory subsystem (e.g., the solid-state drive 101). When the memory subsystem is coupled to the host system 111 through a PCIe interface, the host system 111 can further utilize an NVM Express (NVMe) interface to access the storage capacity of the memory subsystem. The physical host interface can provide an interface for passing control, address, data, and other signals between the host system 111 and the memory subsystem (e.g., the solid state drive 101). Figure 1 Solid state drive 101 is shown as an example memory subsystem. In general, host system 111 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0028] The host system 111 includes a processing device 113 and a controller 115. The processing device 113 of the host system 111 may be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, etc. In some examples, the controller 115 may be referred to as a memory controller, a memory management unit, and / or an initiator. In one example, the controller 115 controls communications on a computer bus 117 coupled between the host system 111 and a memory subsystem (e.g., the solid state drive 101).

[0029] Typically, the controller 115 may send commands or requests to the memory subsystem for desired access to memory storage capacity. The controller 115 may further include interface circuitry to communicate with the memory subsystem via the computer bus 117. The interface circuitry may convert responses received from the memory subsystem into information for the host system 111.

[0030] The controller 115 of the host system 111 may communicate with the controller 115 of the memory subsystem to perform operations such as reading data, writing data, or erasing data and other such operations at the memory components of the memory subsystem. In some examples, the controller 115 is integrated into the same integrated circuit package of the processing device 113. In other examples, the controller 115 is separate from the integrated circuit package of the processing device 113. The controller 115 and / or the processing device 113 may include hardware such as one or more integrated circuits and / or discrete components, buffer memory, cache memory, or a combination thereof. The controller 115 and / or the processing device 113 may be a microcontroller, a dedicated logic circuit system (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor.

[0031] In general, the media unit / memory component of a memory subsystem (e.g., solid-state drive 107 or 109) may include any combination of different types of non-volatile memory components and / or volatile memory components. Examples of non-volatile memory components include non-AND (NAND) type flash memory. Each of the memory components may include one or more arrays of memory cells, such as single-level cells (SLC) or multi-level cells (MLC) (e.g., triple-level cells (TLC) or quad-level cells (QLC)). In some embodiments, a particular memory component may include both an SLC portion and an MLC portion of a memory cell. Each of the memory cells may store one or more data bits (e.g., data blocks) used by the host system 111. Although non-volatile memory components such as NAND type flash memory are described, the memory components may be based on any other type of memory, such as volatile memory. In some embodiments, the memory component may be, but is not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase change memory (PCM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, ferroelectric random access memory (FeTRAM), ferroelectric RAM (FeRAM), conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, electrically erasable programmable read-only memory (EEPROM), nanowire-based nonvolatile memory, memory incorporating memristor technology, and cross-point arrays of nonvolatile memory cells. The cross-point array of the nonvolatile memory may be combined with a stackable cross-grid data access array to perform bit storage based on changes in bulk resistance. In addition, in contrast to many flash-based memories, cross-point non-volatile memories can perform write-in-place operations, where non-volatile memory cells can be programmed without pre-erasing the non-volatile memory cells. In addition, the memory cells of a memory component can be grouped into memory pages or data blocks, which can refer to cells of a memory component used to store data.

[0032] In general, a memory subsystem (e.g., solid-state drive 107 or 109) may have a controller that communicates with memory components of the memory subsystem to perform operations such as reading data, writing data, or erasing data and other such operations (e.g., in response to commands dispatched on a command bus). The controller of the memory subsystem may include hardware such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The controller of the memory subsystem may be a microcontroller, a dedicated logic circuit system (e.g., a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or another suitable processor. The controller of the memory subsystem may include a processing device (e.g., a processor) configured to execute instructions stored in a local memory of the controller. For example, the local memory of the controller of the memory subsystem may include an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines for controlling the operation of the memory subsystem (including handling communications between the memory subsystem and a host system (e.g., 111)). In some embodiments, the local memory may include memory registers that store memory pointers, extracted data, etc. The local memory may also include a read-only memory (ROM) for storing microcode. While typical memory subsystems have a controller, in another embodiment of the present disclosure, the memory subsystem may not include a controller, but may instead rely on external control (eg, provided by an external host or by a processor or controller separate from the memory subsystem).

[0033] Typically, the controller of the memory subsystem (e.g., solid-state drive 107 or 109) may receive commands or operations from the host system 111, and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory components of the memory subsystem. The controller of the memory subsystem (e.g., solid-state drive 107 or 109) may be responsible for other operations, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical block addresses and physical block addresses. The controller of the memory subsystem (e.g., solid-state drive 107 or 109) may further include a host interface circuit system to communicate with the host system (e.g., 111) via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions to access the memory components, and convert responses associated with the memory components into information for the host system (e.g., 111).

[0034] The memory subsystem (e.g., solid-state drive 107 or 109) may also include additional circuitry or components. In some embodiments, the memory subsystem (e.g., solid-state drive 107 or 109) may include a cache memory or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder) that may receive addresses from a controller of the memory subsystem and decode the addresses to access memory components in the memory subsystem.

[0035] The computing system 100 includes a drive aggregator 103 that aggregates the capacity of component solid-state drives 107 to 109 and virtualizes the entire combined capacity into the capacity of a single solid-state drive 101. In some embodiments, the drive aggregator 103 includes logic circuitry to translate commands / requests from a host system 111 into commands / requests to the solid-state drives 107 to 109, and / or translate responses from the solid-state drives 107 to 109 into responses to the host system 111. The drive aggregator 103 accesses commands from the host system 111 according to a communication protocol for the solid-state drive to accept commands from the host system. The drive aggregator 103 constructs commands according to a communication protocol for the host system to issue commands to the solid-state drive and transmits the commands to each of the component solid-state drives (e.g., 107 or 109). The drive aggregator 103 accepts responses from each of the component solid-state drives (e.g., 107 or 109) according to a communication protocol between the host system and the solid-state drive. The drive aggregator 103 constructs a response according to the communication protocol between the host system and the solid-state drive and transmits the response to the host system 111. In one embodiment, the communication protocol used between the host system 111 and the drive aggregator 103 may be the same as the communication protocol used between the drive aggregator 103 and the component solid-state drives 107 to 109. In one embodiment, the communication protocol used between the host system 111 and the drive aggregator 103 may be different from the communication protocol used between the drive aggregator 103 and the component solid-state drives 107 to 109. The drive aggregator 103 behaves like a controller of a standard solid-state drive to the host system 111 according to one communication protocol, and behaves like a standard host system to the component solid-state drives 107 to 109 according to the same or different communication protocol.

[0036] In the solid-state drive 101, the drive aggregator 103 is connected to the component solid-state drives 107 to 109 via a bus 105. For example, the bus 105 may include a point-to-point serial connection from the drive aggregator 103 to the component solid-state drives 107 to 109. The point-to-point serial connection between the drive aggregator 103 and the component solid-state drives 107 to 109 may be in accordance with a Serial Advanced Technology Attachment (SATA) communication protocol, a Peripheral Component Interconnect Express (PCIe) communication protocol, or another protocol. The computer bus 117 between the host system 111 and the drive aggregator 103 may be in accordance with a Serial Advanced Technology Attachment (SATA) communication protocol, a Peripheral Component Interconnect Express (PCIe) communication protocol, a Universal Serial Bus (USB) communication protocol, a Fibre Channel communication protocol, a Serial Attached SCSI (SAS) communication protocol, a Double Data Rate (DDR) memory bus communication protocol, etc.

[0037] The drive aggregator 103 may be implemented using an integrated circuit chip having a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). Alternatively, the drive aggregator 103 may be implemented at least in part via software or firmware. For example, the drive aggregator 103 or a processing device embedded within the drive aggregator 103 may be configured to execute instructions stored in a memory for performing the operations of the drive aggregator 103 described herein. In some embodiments, the drive aggregator 103 is implemented in a single integrated circuit chip configured on an overall solid-state drive 101 having a plurality of component solid-state drives 107.

[0038] Figure 2 A host system 111 is shown connected to a virtualized single solid-state drive having multiple component solid-state drives 107-109. For example, the virtualized single solid-state drive may be used to implement Figure 1 A solid state drive 101 is shown.

[0039] exist Figure 2 In the embodiment, the printed circuit board 131 is configured to have pins 133 for connection 135 to the host system 111 as a single solid-state drive 101. For example, the connection 135 can be a point-to-point serial connection according to SATA, PCIe, USB, or another standard. Based on the communication standard, the host system 111 is configured to recognize the device configured on the printed circuit board 131 as a single solid-state drive 101. The host system 111 addresses the memory in the device based on recognizing the device as a single solid-state drive 101.

[0040] Commands from the host system 111 are received in the drive aggregator 103 via the connection 135 and the pin 133. The received commands are processed in the drive aggregator 103 for adjustment, mapping, and / or distribution to the component solid-state drives 107 to 109. For example, each of the component solid-state drives 107 to 109 may be implemented as a ball grid array (BGA) solid-state drive (SSD) capable of directly processing commands from the host system 111. For example, when the connection 137 from the component solid-state drive 109 to the drive aggregator 103 is directly connected to the host system 111, the host system 111 can recognize the solid-state drive 109 and communicate directly with the solid-state drive 109 to store data in the solid-state drive 109 and / or retrieve data from the solid-state drive 109.

[0041] For example, the BGA SSD 107 may have a controller 141 capable of directly communicating with a host system (eg, 111) to receive commands and provide responses; and the BGA SSD 107 may have a plurality of media units (memory components) 143 to 147 having memory cells for storing data.

[0042] The drive aggregator 103 is configured to shield the details of the component solid-state drives 107-109 from the host system 111. Therefore, the host system 111 does not have to individually address the component solid-state drives 107-109. For example, according to a set of predetermined rules, the drive aggregator 103 may forward some commands from the host system 111 to one component solid-state drive (e.g., 107) and forward other commands from the host system 111 to another component solid-state drive (e.g., 109).

[0043] For example, the drive aggregator 103 may divide the logical address space of the entire capacity of the device configured on the printed circuit board 131 into a plurality of zones. Each of the zones is associated with a corresponding one of the component solid-state drives 107 to 109. When the drive aggregator 103 receives a command received from the host system 111, the drive aggregator 103 determines the zone in which the logical address of the command is located, identifies the target solid-state drive (e.g., 107) associated with the determined zone, adjusts the command to at least map the logical address in the command received in the host to the logical address in the target solid-state drive (e.g., 107), and transmits the adjusted command to the target solid-state drive (e.g., 107).

[0044] In some embodiments, the host system 111 is configured to organize the memory capacity of the virtualized single solid-state drive 101 on the printed circuit board into named portions. The named portions of the memory capacity are namespaces. Logical addresses may be defined within different namespaces separated for the memory capacity of the virtualized single solid-state drive 101. For example, a first namespace allocated on a first portion of the memory capacity of n blocks may have a logical block addressing (LBA) address in the range of 0 to n-1; and a second namespace allocated on a second portion of the memory capacity of m blocks may have an LBA address in the range of 0 to m-1. To access a memory block, the host system 111 identifies a namespace and an LBA address defined within the namespace.

[0045] The drive aggregator 103 may be configured to distribute operations requested by the host system 111 to the component solid-state drives 107 to 109 based on the namespace. For example, the drive aggregator 103 may assign different namespaces created on the memory capacity of the virtualized single solid-state drive 101 to different component solid-state drives 107 to 109. The drive aggregator 103 may then simply forward commands from the host system 111 to the component solid-state drives based on the namespace specified in the command.

[0046] Figure 3 A drive aggregator 103 is shown according to one embodiment. For example, Figure 3 The drive aggregator 103 can be used to Figure 2 The printed circuit board 131 and / or Figure 1 A virtualized single solid state drive 101.

[0047] Figure 3 The drive aggregator 103 can be integrated into a single integrated circuit chip. Figure 3 The drive aggregator 103 includes a host interface 151 for connection 135 to a host system (e.g., 111), a translation logic 153, and a plurality of drive interfaces 155 to 157. Each of the drive interfaces 155 to 157 can be used for connection (e.g., 137) to a component solid-state drive (e.g., 109).

[0048] Host interface 151 is configured to implement the solid state drive side of a communication protocol between a host system and a solid state drive. Each of drive interfaces 155 and 157 is configured to implement the host system side of a communication protocol between a host system and a solid state drive. In some examples, drive interfaces 155-157 may support different communication protocols (e.g., SATA and PCIe) so that different types of component solid state drives 107-109 may be used.

[0049] The translation logic 153 is configured to receive commands from the host interface 151 and generate one or more commands for the drive interfaces 155 to 157. The translation logic 153 generates responses to the commands from the host interface 151 when receiving one or more corresponding responses from the drive interfaces 155 to 157.

[0050] The drive aggregator 103 has an address map 159 that controls the operation of the translation logic 153. For example, the address map 159 can be used to translate logical addresses in the capacity of the virtualized single solid-state drive 101 into corresponding logical addresses in the capacity of a corresponding component solid-state drive (e.g., 107 or 109) connected to one of the drive interfaces 155 to 157. Based on the address translation, the translation logic 153 can generate a corresponding command for the corresponding drive interface (e.g., 155 or 157).

[0051] In some embodiments, the communication protocols used in connection 135 and connection 137 are different. Therefore, translation logic 153 performs command translation based on the difference in communication protocols.

[0052] In some embodiments, the communication protocols used in connection 135 and in connection 137 are different; and translation logic 153 may simply forward commands received in connection 135 to drive interface 157. For example, when a namespace is created on a component solid-state drive (e.g., 109) connected to drive interface 157, commands from host interface 151 for read or write operations in the namespace may be forwarded to drive interface 157.

[0053] The translation logic 153 may be implemented as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or one or more microprocessors that execute an instruction set. The instructions and / or address mapping 159 may be stored in a local memory unit of the drive aggregator 103. Alternatively, or in combination, the instructions and / or address mapping 159 may be stored in one or more of the component solid-state drives (e.g., 107-109) connected to the drive interfaces 155-157.

[0054] Figure 4 A method implemented in the drive aggregator 103 according to one embodiment is shown. For example, Figure 4 The method can be implemented in Figure 1 , 2 and / or the drive aggregator 103 shown in 3.

[0055] At block 201, the drive aggregator 103 receives a command from the host system 111. The command specifies an operation to be performed by the solid-state drive 101. The drive aggregator 103 acts as a controller for a single solid-state drive 101 to the host system 111. Therefore, commands from the host system 111 to the drive aggregator are configured to address the same solid-state drive 101. The drive aggregator 103 is connected to a plurality of solid-state drives 107 to 109.

[0056] At block 203, the drive aggregator 103 maps the address in the command from the host system 111 to an address in a solid-state drive (e.g., 107 or 109) among the plurality of solid-state drives 107 to 109 connected to the drive aggregator 103. The mapping may be based on a namespace specified in the command from the host system 111, a predetermined address mapping scheme, and / or the address map 159.

[0057] At block 205, the drive aggregator 103 generates commands and transmits the commands to the solid-state drive (e.g., 107 or 109). The commands to the solid-state drive (e.g., 107 or 109) are configured for the operation specified in the command received from the host system 111 and for the address mapped in the solid-state drive (e.g., 107 or 109).

[0058] For example, logical addresses defined in a namespace created in the memory capacity of a single solid-state drive 101 may be mapped to the same logical addresses defined in a namespace created in the memory capacity of a solid-state drive (e.g., 107 or 109) assigned to implement the namespace.

[0059] For example, the space of logical addresses defined in the entire memory capacity of a single solid-state drive 101 represented by the drive aggregator 103 may be divided into zones (e.g., according to a predefined scheme). Different zones may be mapped to the space of logical addresses defined in the memory capacity of component solid-state drives 107 to 109.

[0060] When the communication protocol between the host system 111 and the drive aggregator 103 is different from the communication protocol between the drive aggregator 103 and the component solid-state drives 107 to 109 , the drive aggregator 103 may perform command translation according to the communication protocol.

[0061] When the communication protocol between the host system 111 and the drive aggregator 103 is the same as the communication protocol between the drive aggregator 103 and the component solid-state drives 107 to 109, in some embodiments (e.g., when the address mapping is namespace-based), the drive aggregator 103 may be configured to forward the command to the target solid-state drive 101 without change.

[0062] For example, the communication protocol between the host system 111 and the drive aggregator 103, and the communication protocol between the drive aggregator 103 and the component solid-state drives 107 to 109, and the drive aggregator 103 may each be any one of the standard protocols, such as the protocol for the Serial Advanced Technology Attachment (SATA) interface, the protocol for the Peripheral Component Interconnect Express (PCIe) interface, the protocol for the Universal Serial Bus (USB) interface, the protocol for the Fibre Channel, etc.

[0063] At block 207 , the drive aggregator 103 receives a response from the solid-state drive (eg, 107 or 109 ) in response to the command to the solid-state drive (eg, 107 or 109 ).

[0064] At box 209, the drive aggregator 103 generates a response based on the response from the solid state drive (e.g., 107 or 109) and transmits the response to the host system 111, wherein the response to the host system is in response to a command from the host system for the operation and address specified in the command from the host system.

[0065] In some embodiments, the drive aggregator 103 performs protocol translation to account for protocol differences between the connection 135 of the host system 111 and the connection (e.g., 137) to the component solid-state drive (e.g., 109). In other embodiments, the drive aggregator 103 performs further adjustments to the response to the host system 111 to account for logical address differences between commands from the host system 111 and commands to the component solid-state drive (e.g., 109).

[0066] Figure 5 A method of distributing commands received in a virtualized solid-state drive to a solid-state drive is presented. For example, Figure 5 The method can be implemented on Figure 2 The components of the configuration shown in the solid state drives 107 to 109 are Figure 1 In the virtualized solid state drive 101. For example, Figure 5 The method can be implemented in Figure 1 , 2 and / or the drive aggregator 103 shown in 3.

[0067] At box 241 , the drive aggregator 103 virtualizes the plurality of solid-state drives 107 to 109 into a single solid-state drive 101 connected to the host system 111 .

[0068] At box 243 , the drive aggregator 103 receives a first command from the host system 111 to create a namespace on the capacity of the virtualized solid-state drive 101 .

[0069] At block 245 , the drive aggregator 103 selects a solid-state drive (eg, 107 or 109 ) from the plurality of solid-state drives 107 to 109 for the namespace.

[0070] At box 247, the drive aggregator 103 stores data associating the namespace with the selected solid-state drive (e.g., 107 or 109).

[0071] At box 249, the drive aggregator 103 transmits a first command to the selected solid-state drive (eg, 107 or 109) to create a namespace in the selected solid-state drive (eg, 107 or 109).

[0072] At block 251 , the drive aggregator 103 receives a second command from the host system 111 identifying a namespace.

[0073] At block 253 , the drive aggregator 103 transmits a second command to the selected solid-state drive (eg, 107 or 109 ) based on the association of the namespace with the selected solid-state drive.

[0074] like Figure 5 The technique of distributing commands to the component solid-state drives 107 to 109 may simplify the translation logic 153 of the drive aggregator 103 and thereby reduce the complexity, energy consumption, and cost of the translation logic 153.

[0075] In some embodiments disclosed herein, a single solid-state drive is configured with multiple physical host interfaces that allow multiple host systems to access the memory / storage capacity of the solid-state drive. In some embodiments, the host system can use multiple parallel and / or redundant connections to the multiple physical host interfaces of the solid-state drive to improve performance and / or reliability.

[0076] Figure 6 Multiple host systems 111-112 are shown connected to a virtualized single solid-state drive 101 configured on a printed circuit board 131 having multiple component solid-state drives 107-109.

[0077] Similar to Figure 2 The solid state drive 101 shown in FIG. Figure 6 The solid state drive 101 shown in FIG. 1 can be constructed using a plurality of BGA SSDs (e.g., 107) as component solid state drives 107 to 109. Each component solid state drive (e.g., 107) has a controller (e.g., 141) that can directly serve the host system (e.g., 111) without the drive aggregator 103 when the component solid state drive (e.g., 107) is directly connected to the host system (e.g., 111).

[0078] The drive aggregator 103 is configured to virtualize the memory / storage capacity of the set of component solid-state drives 107 - 109 into the memory / storage capacity of a single virtualized solid-state drive 101 , and into a uniform memory / storage resource for the host systems 111 - 112 .

[0079] The printed circuit board 131 is configured with a plurality of sets of pins 133 to 134. Each set of pins (e.g., 133 or 134) is sufficient to establish a connection between the host system (e.g., 111 or 112) and the solid-state drive 101 so as to fully access the solid-state drive 101. For example, the host system (e.g., 111 or 112) can use any set of pins (e.g., 133 or 134) to transmit a command or request to the solid-state drive 101, and receive a response to the corresponding command or request.

[0080] Multiple sets of pins 133 to 134 allow Figure 6 The host systems 111-112 in the 100 device 100 communicate with the solid-state drive 101 using parallel connections 135-136, respectively. For example, the host system 111 may send a command / request to the solid-state drive 101 via connection 135 and pin 133, while the host system 112 may send a similar command / request (or a different type of command / request) to the solid-state drive 101 via another connection 136 and an alternative pin 134. For example, the host system 111 may send a write command at the same time as the host system 112 sends a write command or a read command to the solid-state drive 101. Thus, the host systems 111-112 may share the memory / storage resources provided by the solid-state drive 101 as a whole.

[0081] Figure 6 The drive aggregator 103 can service commands / requests from each host system (e.g., 111 or 112) in a manner similar to Figure 2-5 Shown in and about Figure 2-5 The drive aggregator 103 is described.

[0082] In some examples, when two simultaneous commands are mapped to the same component solid-state drive (e.g., 107 or 109) for execution, Figure 6 The drive aggregator 103 may further resolve conflicts by scheduling commands for non-simultaneous execution, as discussed further below.

[0083] Figure 7 A drive aggregator 103 is shown having multiple host interfaces 151-152 according to one embodiment. For example, Figure 7 The drive aggregator 103 can be Figure 8 The solid state drive 101 is used.

[0084] Figure 7The translation logic 153 may be based on the address mapping 159 in a manner similar to Figure 3 The translation logic 153 distributes commands received in the host interface (eg, 151 or 152 ) to the drive interfaces 155 to 157 .

[0085] In addition, when multiple commands are received simultaneously in multiple host interfaces 151-152, the operation of the commands may be mapped to different drive interfaces in some cases and to the same drive interface in other cases. For example, when multiple commands are configured to operate on logical addresses associated with the same drive interface 155, conflicts occur. The conflicts prevent the translation logic 153 from executing commands simultaneously in parallel using the drive interfaces. In this case, the translation logic 153 can use the command queue 161 to schedule the sequential execution of the commands to avoid conflicts.

[0086] When there is no conflict, multiple commands received simultaneously in multiple host interfaces 151-152 can be executed in parallel by separate component solid-state drives (e.g., 107-109) respectively connected to drive interfaces 155-157. The execution can be performed in some embodiments by generating corresponding commands for component solid-state drives (e.g., 107-109) or by forwarding the received commands to the corresponding drive interfaces 155-157.

[0087] When there is a conflict, the translation logic 153 may use the command queue 161 to schedule sequential execution of conflicting commands received from different host interfaces 151 to 152. For example, when two commands received in the host interfaces 151 and 152 identify the same name space (or logical address area) associated with the drive interface 155 according to the address map 159, the translation logic 153 may queue one of the commands in the command queue 161 and forward the other command to the drive interface 155 (or generate and transmit a corresponding command for the operation of the other command after appropriate protocol and / or address translation). Subsequently, the translation logic 153 may retrieve the remaining commands from the command queue 161 and forward them to the drive interface (or generate and transmit a corresponding command for the operation of the command retrieved from the command queue after appropriate protocol and / or address translation).

[0088] In some implementations, the translation logic 153 does not support the execution of commands received from the host interface (e.g., 151 or 152) in the order in which the commands are received from the host interface (e.g., 151 or 152). The translation logic 153 can arrange the execution order of the commands via the command queue to increase the parallel transmission of commands to the drive interfaces 155 to 157, and thus improve the overall performance of the solid-state drive 101 having the drive aggregator 103.

[0089] In some examples, two or more of host interfaces 151 - 152 may be used by the same host system to increase communication bandwidth to a drive aggregator and / or to improve reliability in connections to a drive aggregator.

[0090] Figure 8 A host system 111 is shown connected to a virtualized single solid-state drive 101 via multiple parallel and / or redundant connections 135-136. For example, Figure 8 Virtualizing a single solid state drive 101 can be used Figure 7 The drive aggregator 103 is similar to Figure 6 The virtualization of a single solid-state drive 101 is implemented.

[0091] exist Figure 8 In the example, a single solid-state drive 101 is virtualized to have Figure 7 133 to 134 are connected to separate host system pins. Figure 8 In the example of , multiple sets of pins 133-134 of the solid-state drive 101 are connected to the same host system 111 via parallel redundant connections. Thus, the host system 111 can use any of the connections to send specific commands to the solid-state drive 101 (e.g., write / store data in a memory cell or read / retrieve data from a memory cell).

[0092] For example, when one of the connections (eg, 135 or 136) fails, the host system 111 can use the remaining connection (eg, 136 or 135) to access the memory / storage capacity of the solid state drive 101. Thus, the reliability of the system is improved.

[0093] In addition, the host system 111 may send multiple commands in parallel to the solid-state drive 101 for execution via the connections 135 to 136. For example, the host system 111 may send a read command via the connection 135 while sending a write command via the connection 136. For example, the host system 111 may use the connection 135 for a read data stream stored into a namespace configured on the component solid-state drive 107 while using the connection 136 for a write data stream retrieved from another namespace configured on another component solid-state drive 109.

[0094] Fig. 9 A method of processing commands received in a virtualized solid-state drive 101 via a plurality of host interfaces 151 to 152 is shown. For example, Fig. 9 The method can be implemented in Figure 6 or 8 in the configuration shown in FIG. 8 having components solid state drives 107 to 109 Figure 1 In the virtualized solid state drive 101. For example, Fig. 9The method can be implemented in Figure 6 , 7 and / or the drive aggregator 103 shown in 8. In addition, Fig. 9 The method can be used with Figure 4 And / or a combination of the 5 methods.

[0095] At block 271 , a drive aggregator 103 having at least two host interfaces (eg, 151 and 152 ) simultaneously receives a first command in a first host interface (eg, 151 ) and a second command in a second host interface (eg, 152 ).

[0096] At box 273, the translation logic 153 of the drive aggregator 103 determines whether the first and second commands are to be executed in the same solid-state drive (e.g., 107 or 109) among multiple solid-state drives 107 to 109 connected to the drive aggregator 103 via the drive interfaces 155 to 157 of the drive aggregator 103.

[0097] At box 275 , a determination guide box 279 of first and second commands will be executed in the same solid state drive (eg, 107 or 109 ); and a determination guide box 279 of first and second commands will be executed in different solid state drives (eg, 107 and 109 ).

[0098] For example, for each corresponding command in the first and second commands received in the host interface (e.g., 151 and 152), the translation logic 153 may determine the memory unit to be operated. For example, the memory unit may be operated for reading data or for writing data according to the logical address specified in the corresponding command. When the memory unit is determined to be in a component solid-state drive (e.g., 107 or 109) connected to the drive interface (e.g., 155 or 157), the corresponding command will be executed in the component solid-state drive (e.g., 107 or 109). For example, the address mapping 159 may be used to identify the component solid-state drive (e.g., 107 or 109) based on the logical address of the memory unit specified in the corresponding command and / or the name space of the logical address (e.g., as described above in conjunction with Figure 4 and 5 When each command is mapped to a component solid-state drive (e.g., 107 or 109), multiple simultaneous commands may be mapped to the same component solid-state drive (e.g., 107 or 109) in some instances, and not mapped to any of the same component solid-state drives (e.g., 107 or 109) in other instances.

[0099] At box 277, the translation logic 153 transmits the commands to two of the plurality of solid-state drives 107-109 in parallel to perform operations of the first and second commands because the first and second commands do not operate on the same component solid-state drive (eg, 107 or 109).

[0100] At block 279, the translation logic 153 schedules the commands for sequential transmission to the same solid state drive (eg, 107 or 109) to perform operations of the first and second commands because the first and second commands operate on the same component solid state drive (eg, 107 or 109). Sequential transmission resolves conflicts.

[0101] Similar to Figure 4 and 5 In the operations, commands transmitted to the solid-state drive in parallel or sequentially to execute the operations of the first and second commands may involve protocol translation and address translation.

[0102] For example, when the communication protocol on host connections 135-136 is different than the communication protocol on the drive connection (eg, 137), translation logic 153 translates from the protocol for the first and second commands to commands to drive interfaces 155-157.

[0103] For example, when the communication protocol on host connection 135 to 136 is the same as the communication protocol on the drive connection (e.g., 137) and the address mapping 159 is based on an association between a namespace and a component driver that hosts the namespace, the translation logic 153 may simply forward the first and second commands as corresponding commands to the drive interfaces 155 to 157.

[0104] For example, when the address mapping 159 is used to map the LBA address region in the command received in the host interface 151 to 152 to a different LBA address in the component solid-state drive 157 to 159, the translation logic 153 may replace the LBA address in the command received in the host interface 151 to 152 with the mapped LBA address calculated according to the address mapping 159 for the corresponding component solid-state drive 157 to 159.

[0105] In at least some embodiments disclosed herein, a single solid-state drive is virtualized with one or more component solid-state drives and at least one spare solid-state drive that provides redundancy for at least a portion of the memory / storage resources of the solid-state drive. The spare solid-state drive stores redundant copies of at least some of the data stored in the memory subsystem and / or provides additional spare memory / storage capacity, so that when a component solid-state drive fails, the redundant copies of the data and / or the additional memory / storage capacity in the spare solid-state drive can be used to facilitate continued operation without catastrophic failure.

[0106] For example, when such a virtualized single solid-state drive is configured in a vehicle, the spare solid-state drive allows the memory subsystem to facilitate continued operation of the vehicle, as designed when one or more of the component solid-state drives fail during operation of the vehicle. The redundant content and / or additional memory / storage capacity in the spare solid-state drive allows the vehicle to remain operational and / or enter an emergency mode to render the vehicle to a safe state (e.g., by slowing down and / or stopping). Thus, potential accidents can be avoided.

[0107] Fig.10 A virtualized single solid-state drive 101 is shown with multiple component solid-state drives 107-109 and a spare solid-state drive 106 for fail-safe operation. Spare solid-state drive 106 may also be a BGASSD, similar to component solid-state drive 107, for example.

[0108] In some embodiments, the spare solid-state drive 106 has a memory / storage capacity that is significantly smaller than the component state driver (e.g., 107 or 109) in order to reduce costs. The spare solid-state drive 106 can be used to store a reduced instruction set and / or data, which allows the system to operate at a designed level with reduced functionality compared to the normal mode. In addition, the spare solid-state drive 106 can be configured with a reduced amount of free memory / storage space for continuous operation within a time window, which allows the system to remain operational until the system can be safely repaired. Optionally, the spare solid-state drive 106 can have a memory / storage capacity as large as the component state driver (e.g., 107 or 109). In other embodiments, multiple spare solid-state drives can be used.

[0109] Fig.10 An example is shown in which a single solid-state drive 101 is virtualized with multiple sets of pins 133 to 134 for parallel and / or redundant connections 135 to 136 in a manner similar to Figure 6 In general, it is not necessary to have multiple sets of pins 133-134 to implement a fault protection mechanism. For example, the backup solid state drive 106 may be implemented with a set of pins 133 for connection 135 to a host system 111. Figure 2 of drive 101.

[0110] The failover setting may be configured in the drive aggregator 103 to map mission-critical portions of the component solid-state drives 107 to 109 to corresponding zones in the spare solid-state drive 106. Based on the failover setting, the drive aggregator 103 may maintain redundant data and perform failover to the spare solid-state drive 106 after a component solid-state drive (e.g., 107) fails without an instruction or request from the host system (e.g., 111).

[0111] For example, the namespace in the solid-state drive 109 may be configured to store mission-critical data, such as instructions, an operating system, one or more applications, and / or configuration data for the operating system and applications. When a namespace is identified as having a priority above a threshold (or otherwise designated / identified for data redundancy), the drive aggregator 103 automatically maintains a replica of the namespace in the solid-state drive 109.

[0112] For example, in response to a command from the host system (e.g., 111) to create a high priority namespace, the drive aggregator 103 sends a command to the component solid-state drive (e.g., 107) to create a namespace in the component solid-state drive (e.g., 107) and stores the data address map 159 to associate the namespace with the component solid-state drive (e.g., 107). The priority of the namespace may be indicated via an identifier of the namespace or an attribute of the namespace. In response to determining that the namespace has a high priority, the drive aggregator 103 further sends a command to the spare solid-state drive (e.g., 107) to create the namespace in the spare solid-state drive (e.g., 107).

[0113] When a command from a host system (e.g., 111) is received in the drive aggregator 103 to store data in a high priority namespace, the drive aggregator 103 sends the command to both the spare solid-state drive 106 and the component solid-state drive (e.g., 107) so that a copy of the data in the namespace configured in the component solid-state drive (e.g., 107) is available in the corresponding namespace in the spare solid-state drive 106.

[0114] When a command from the host system (e.g., 111) is received in the drive aggregator 103 to retrieve data from the high priority namespace, the drive aggregator 103 sends a command to the component solid-state drive (e.g., 107) to retrieve the data. When the component solid-state drive (e.g., 107) fails to retrieve the requested data, the drive aggregator 103 sends a command to the spare solid-state drive 106 to retrieve the requested data. When the component solid-state drive (e.g., 107) is operating, the read command is not executed in the spare solid-state drive 106, so that the spare solid-state drive 106 is subjected to less workload and stress than the component solid-state drive (e.g., 107).

[0115] The drive aggregator 103 is configured to monitor the operating status of the component solid-state drives 107 to 109. When a component solid-state drive (e.g., 107) determines that a failure has occurred, the drive aggregator 103 can adjust the address map 159 to remap the name space to the spare solid-state drive 106. Therefore, when the component solid-state drive (e.g., 107) has occasional failures / data corruptions and / or when the component solid-state drive (e.g., 107) fails completely, the host system (e.g., 111) can continue to operate.

[0116] In general, there may be multiple high priority namespaces with replicas in the spare solid state drive 106. The drive aggregator 103 may distribute the high priority namespace among the component solid state drives 107 to 109. Alternatively, the drive aggregator 103 may use one of the component solid state drives 107 to 109 to host the high priority namespace.

[0117] Optionally, when one of the component solid-state drives 107 to 109 fails, the drive aggregator 103 may remap the namespace previously managed in the solid-state drive 108 to the remaining operational component solid-state drives of the component solid-state drives 107 to 109. The high-priority namespace having a replica in the spare solid-state drive 106 may be replicated and remapped to one or more of the remaining operational component solid-state drives of the component solid-state drives 107 to 109. The low-priority namespace having no replica in the spare solid-state drive 106 may be regenerated with empty content. Thus, when a component solid-state drive fails, the drive aggregator 103 may redistribute the namespace among the remaining component solid-state drives to automatically restore the functionality of the system without assistance from the host system (e.g., 111).

[0118] When a component solid-state drive (e.g., 107 or 109) fails, the drive aggregator 103 may be configured to report errors to the host system (e.g., 111). For example, the drive aggregator 103 may be configured to report data loss in a particular namespace that does not have a replica in the spare solid-state drive 106. In addition, the drive aggregator 103 may report to the host system (e.g., 111) that the memory / storage capacity of the solid-state drive 101 is reduced due to the failed component solid-state drive (e.g., 107 or 109). The host system (e.g., 111) may therefore take further action to put the system into a safe state.

[0119] In the above examples, replication and failover are discussed based on address mapping according to namespaces. Generally speaking, address mapping can be based on logical address regions or partitions (e.g., LBA addresses defined in the entire memory / storage capacity of the solid-state drive 101). Therefore, replication and failover can be similarly configured based on logical address regions or partitions.

[0120] Fig.11 A drive aggregator 103 is shown configured to perform failover according to one embodiment. For example, Fig.11 The drive aggregator 103 can be Fig.10 The solid state drive 101 is used.

[0121] Fig.11 An example is shown in which the drive aggregator 103 has multiple host interfaces 151 to 152 for parallel and / or redundant connections 135 to 136 in a manner similar to Figure 7 In general, it is not necessary to have multiple host interfaces 151 to 152. For example, a drive aggregator 103 of one embodiment with failover capability may have only one host interface, in a manner similar to Figure 3 The drive aggregator 103.

[0122] The translation logic 153 is configured to manage an address mapping 159 for mapping logical addresses specified in commands received in the host interfaces 151 - 152 to logical addresses of solid-state drives connected to the drive interfaces 155 - 157 .

[0123] Fig.11 The drive aggregator 103 has a function for connecting to a spare solid state drive (e.g., Fig.10 106) of the drive interface 158 connected to 138.

[0124] The address map 159 further includes a failover setting 154 that identifies mappings between some logical addresses in the component solid-state drives 107 to 109 connected to the drive interfaces 155 to 157 and corresponding logical addresses in the spare solid-state drive 106 connected to the drive interface 158. For example, the failover setting 154 may be implemented by associating a namespace with both a drive interface (e.g., 157) connected to the component solid-state drive (e.g., 109) and a drive interface (e.g., 158) connected to the spare solid-state drive (e.g., 109). For example, the failover setting 154 may be implemented by associating an LBA address range defined in the entire capacity of the solid-state drive 101 with both an LBA address range defined in the capacity of the component solid-state drive (e.g., 109) connected to the corresponding drive interface (e.g., 157) and an LBA address range defined in the capacity of the spare solid-state drive (e.g., 106) connected to the spare drive interface 158.

[0125] According to the failover setting 154, the translation logic 153 replicates the write commands directed to the drive interfaces 155 to 157 for the component solid-state drives 107 to 109 and generates corresponding write commands for the interface 158 for the spare solid-state drive 106. Therefore, a backup copy of the data stored in the logical address specified in the failover setting 154 can be generated in the spare solid-state drive 106.

[0126] When a component solid state drive (e.g., 107) fails, translation logic 153 adjusts address mapping 159 to map corresponding addresses to spare drive interface 158. Thus, the host system (e.g., 135 or 136) can instantly access the replicated data in spare drive 106 with minimal or zero downtime.

[0127] When the drive aggregator 103 has only one host interface 151 , the command queue 161 may be eliminated in some embodiments.

[0128] When the drive aggregator 103 has multiple host interfaces 151 to 152, different commands received simultaneously in different host interfaces (e.g., 151 and 152) may be mapped according to the failover setting 154 to write data to the spare solid-state drive 106 via the same interface 158. In this case, the translation logic 153 may use the command queue 161 to schedule non-simultaneous execution of commands in the spare solid-state drive 106.

[0129] Fig.12 An example of changing the failover settings 154 for failover and recovery is shown. For example, Fig.12 Examples can be implemented in Fig.11 The drive aggregator 103 neutralizes Fig.10The solid state drive 101 is configured to:

[0130] exist Fig.12 In FIG. 1 , namespaces 171 and 173 are configured to be associated with drive interfaces 155 and 157, respectively, for normal operation. In addition, namespaces 171 and 173 are associated with interface 158 to enable connection 138 to backup solid-state drive 106.

[0131] During normal operation, the failover setting 154 causes the drive aggregator 103 to build a replica of the data in the namespaces 171 and 173 in the spare solid-state drive 106 by mirroring data modification operations in the namespaces 171 and 173 in the component solid-state drives (e.g., 107 and 109) connected to the drive interface. For example, write commands in the namespaces 171 and 173 are forwarded not only to the drive interfaces 155 and 157, but also to the interface 158 for the spare solid-state drive 106. However, the execution of commands that do not change the data sets in the namespaces 171 and 173 (e.g., read commands) are not mirrored in the spare solid-state drive 106.

[0132] When a component solid-state drive (e.g., 107) connected to drive interface 155 fails, drive aggregator 103 may modify failover settings 154 to remove the association between namespace 171 and drive interface 155. Thus, once namespace 171 is no longer associated with a drive interface (e.g., 155 or 157) for a component solid-state drive (e.g., 107 or 109), modified failover settings 154 cause drive aggregator 103 to forward all commands in namespace 171 to interface 158 for spare solid-state drive 106. Modified failover settings 154 allow drive aggregator 103 to execute all commands in namespace 171 without error.

[0133] Optionally, the drive aggregator 103 may automatically perform a data recovery operation for the namespace 171. During the data recovery operation, the drive aggregator 103 identifies the operating component solid-state drive (e.g., 109) and recreates the namespace 171 in the operating component solid-state drive (e.g., 109). The drive aggregator 103 copies the data from the namespace 171 in the spare solid-state drive 106 to the namespace 171 in the component solid-state drive 106. During the data recovery cycle, the drive aggregator 103 mirrors the execution of commands that change the data set in the namespace 171 in both the operating component solid-state drive (e.g., 109) and the spare solid-state drive 106. After the data is recovered, the drive aggregator 103 updates the failover settings 154 to associate the namespace 171 with both the drive interface 157 connected to the operating component solid-state drive (e.g., 109) and the interface 158 for the spare solid-state drive 106. Therefore, the drive aggregator 103 can restore normal operation at least for the namespace 171.

[0134] Fig.13 Demonstrate methods for failing over to a spare solid-state drive. For example, Fig.13 The method can be implemented on Fig.10 The components of the solid state drives 107 to 109 in the configuration shown in FIG. Figure 1 In the virtualized solid state drive 101. For example, Fig.13 The method can be implemented in Fig.10 and / or the drive aggregator 103 shown in 11, having Fig.12 The failover settings shown in the figure are changed. In addition, Fig.13 The method can be used with Figure 4 , 5 and / or the method in 9 are used in combination.

[0135] At box 281 , the solid state drive 101 is provided to have a plurality of component solid state drives 107 to 109 , a spare solid state drive 106 , and a drive aggregator 103 .

[0136] In some embodiments, only one component solid-state drive (eg, 107) is used in solid-state drive 101. In other embodiments, solid-state drive 101 has multiple component solid-state drives 107-109.

[0137] At block 283, the drive aggregator 103 receives, via at least one host interface (eg, 151), a command to operate a memory cell identified via a logical address.

[0138] For example, the command may include a command to read data from a logical address and / or a command to write data into a logical address. The logical address in the command from the host system is defined for the solid-state drive 101 as a whole. The drive aggregator 103 may have translation logic 153 to translate / forward commands for the component solid-state drives 107-109.

[0139] At block 285, the drive aggregator 103 implements the command (e.g., as described above in connection with Figure 2-9 discussed).

[0140] At box 287 , the drive aggregator 103 maintains, in the spare solid-state drive 103 , a copy of the data set stored in a first component solid-state drive (eg, 107 ) of the plurality of component solid-state drives 107 to 109 .

[0141] For example, the drive aggregator 103 in one embodiment is configured to mirror data change operations for a data set in the first component solid-state drive (eg, 107 ) and in the spare solid-state drive 106 .

[0142] Preferably, the drive aggregator 103 is configured to not mirror non-data changing operations (e.g., read operations) performed on the data set in the first component solid-state drive (e.g., 107) to reduce energy consumption and reduce the workload on the spare solid-state drive 106.

[0143] In some embodiments, each of the component solid-state drives 107 to 109 and the spare solid-state drive 106 are packaged in an integrated circuit package having a ball grid array (BGA) form factor. The spare solid-state drive 106 may have a smaller capacity than each of the component solid-state drives 107 to 109. Therefore, some data sets stored in the component solid-state drives 107 to 109 may not have a replica in the spare solid-state drive 106.

[0144] For example, data sets with replicas may be identified via namespaces (or logical address regions defined on the memory / storage capacity of solid-state drive 101 as a whole). Multiple namespaces may be identified by the host system (e.g., 111) as high priority namespaces that require replicas in spare solid-state drive 106. The high priority namespaces may be distributed among component solid-state drives 107-109.

[0145] At block 289, in response to the failure of the first component solid-state drive (e.g., 107), the drive aggregator 103 replaces the functionality of the first component solid-state drive (e.g., 107) with respect to the data set with the corresponding functionality of the spare solid-state drive 106 based on the copy of the data set maintained in the spare solid-state drive 106. Thus, the functionality of the first component solid-state drive (e.g., 107) with respect to the data set can fail over to the spare solid-state drive 106 without assistance from the host system (e.g., 111).

[0146] After failure of a first component solid-state drive (e.g., 107), the drive aggregator 103 is optionally configured to select a second component solid-state drive (e.g., 109) from the plurality of component solid-state drives 107 to 109 and rebuild the data set in the second component solid-state drive (e.g., 109).

[0147] The first component solid-state drive (e.g., 107) that failed may store other data sets identified via other namespaces that do not have replicas in the spare solid-state drive 106. After the first component solid-state drive (e.g., 107) fails, the drive aggregator 103 may be configured to optionally generate such namespaces on the spare solid-state drive 106 or the remaining set of operational component solid-state drives to allow the host system (e.g., 111) to record new data into these namespaces as if the existing data in the namespaces had been erased via a command from the host system (e.g., 111).

[0148] The above (for example, in conjunction with Figure 4 , 5 , 9 and / or 13) may be performed by processing logic, which may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microcode, hardware of the device, integrated circuit, etc.), software (e.g., instructions running or executed on the processing device), or a combination thereof. In some embodiments, Figure 4 , 5 , 9 and / or 13 are at least partially Figure 1 , 2 , 3, 6, 7, 8, 10, or 11 of the drive aggregator 103. Although shown in a particular sequence or order, unless otherwise specified, the order of operations may be modified. Therefore, it should be understood that the embodiments shown are only examples, and the operations shown may be performed in a different order, and some operations may be performed in parallel. In addition, one or more operations may be omitted in various embodiments. Therefore, not all operations are required in every embodiment. Other operation flows are possible.

[0149] In some embodiments, the communication channel between the host system 111 and the memory subsystem (e.g., the solid-state drive 101) includes a computer network, such as a local area network, a wireless local area network, a wireless personal area network, a cellular communication network, a broadband high-speed always-connected wireless communication connection (e.g., a current or future generation of mobile network links); and the host system 111 and the memory subsystem may be configured to communicate with each other using data storage management and usage commands similar to those in the NVMe protocol.

[0150] Some embodiments involving the operation of the drive aggregator 103 may be implemented using computer instructions executed by one or more microprocessors. The computer instructions may be configured as firmware for the solid-state drive 101. In some examples, hardware circuits may be used to implement at least some of the functionality. The firmware may be initially stored in a non-volatile storage medium or another non-volatile device and loaded into volatile DRAM and / or processor cache for execution by the microprocessor of the drive aggregator.

[0151] Non-transitory computer storage media may be used to store instructions for firmware of a memory subsystem (eg, solid state drive 101, or any of component solid state drives 107 to 109). When the instructions are executed by a microprocessor, the instructions cause the memory subsystem to perform the methods discussed above.

[0152] Generally speaking, an example machine of a computer system may have an instruction set for causing the machine to perform any one or more of the methods discussed herein. In some embodiments, this computer system may correspond to a host system (e.g., Figure 1 A host system 111 that includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1 The solid state drive 101 may be used to perform operations of the drive aggregator 103 (e.g., execute instructions to perform operations corresponding to the reference Figure 1-13 In some embodiments, the machine may be connected (e.g., using a network) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the form of a server or a client machine in a client-server network environment, or in the form of a server or a client machine in a peer-to-peer (or distributed) network environment.

[0153] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions that specify actions to be taken by the machine. In addition, while a single machine is shown, the term "machine" should also be construed to include any collection of machines that individually or collectively execute one (or more) sets of instructions to perform any one or more of the methodologies discussed herein.

[0154] An example machine may include a processing device, a main memory (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), static random access memory (SRAM), etc.), and a data storage system, which communicate with each other via a bus (which may include multiple buses).

[0155] The processing devices discussed herein may include one or more general-purpose processing devices, such as microprocessors, central processing units, and the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. The processing devices discussed herein may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, and the like. The processing devices are typically configured to execute instructions for performing the operations and steps discussed herein. The example machine may further include a network interface device for communicating via a computer network.

[0156] The data storage system disclosed herein may include a machine-readable storage medium (also referred to as a computer-readable medium) on which is stored one or more sets of instructions or software embodying any one or more of the methods or functions described herein. The instructions may also reside completely or at least partially in a main memory and / or a processing device during execution by a computer system, the main memory and the processing device also constituting a machine-readable storage medium. The machine-readable storage medium, the data storage system, and / or the main memory may correspond to a memory subsystem.

[0157] In one embodiment, the instructions stored in the example machine include instructions to implement functionality corresponding to the driver aggregator 103 (e.g., as described in reference to Figure 1-13). Although the machine-readable storage medium may be discussed as a single medium in one embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing the one or more instruction sets. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure. Therefore, the term "machine-readable storage medium" should be considered to include (but not limited to) solid-state memory, optical media, and magnetic media.

[0158] Some portions of the previous detailed description have been presented with respect to algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing can most effectively convey the substance of their work to other persons skilled in the art. An algorithm is here and generally considered to be a self-consistent sequence of operations that leads to a desired result. An operation is an operation that requires physical manipulation of physical quantities. These quantities are usually, but not necessarily, in the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Sometimes, primarily for general reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0159] It should be borne in mind, however, that all of these and similar terms should be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may be directed to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within a computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0160] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the desired purpose, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic optical disks), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0161] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods. The structures of various such systems will be presented as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It should be appreciated that the teachings of the present disclosure as described herein may be implemented using various programming languages.

[0162] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, etc.

[0163] In this specification, various functions and operations are described as being performed by or caused by computer instructions to simplify the description. However, those skilled in the art will recognize that the intent of such expressions is that the functions are derived from one or more controllers or processors (e.g., microprocessors) executing computer instructions. Alternatively or in combination, the functions and operations may be implemented using dedicated circuitry with or without software instructions, such as using an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). Embodiments may be implemented using hardwired circuitry without software instructions or in combination with software instructions. Therefore, the technology is neither limited to any particular combination of hardware circuitry and software, nor to any particular source of instructions executed by a data processing system.

[0164] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings should be viewed in an illustrative rather than a restrictive sense.

Claims

1. A solid state drive comprising: at least one component solid state drive; a spare solid-state drive having a storage capacity less than any one of the at least one component solid-state drive; as well as A driver aggregator with: at least one host interface; at least one drive interface connected to the at least one component solid state drive; as well as an interface connected to the backup solid state drive; wherein the drive aggregator is configured to maintain in the spare solid-state drive a copy of the data set stored in the component solid-state drive and reserve a portion of the storage capacity of the spare solid-state drive until the component solid-state drive fails; wherein the drive aggregator is configured to shield the at least one component solid-state drive and the spare solid-state drive from direct access by a host system by virtualizing an aggregate capacity of the at least one component solid-state drive and the spare solid-state drive as a combined capacity of the solid-state drives, wherein the host system accesses the combined capacity based on transmitting a command addressed to the solid-state drive; and Wherein, in response to the failure of the component solid-state drive, the drive aggregator is configured to replace a function of the component solid-state drive relative to the data set with a corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

2. The solid-state drive of claim 1, wherein the drive aggregator is configured to mirror data change operations for the data set in the component solid-state drive and in the spare solid-state drive. 3 . The solid-state drive of claim 2 , wherein the spare solid-state drive has a smaller capacity than the component solid-state drive.

4. The solid-state drive of claim 2, wherein the solid-state drive has a plurality of component solid-state drives; the drive aggregator has a plurality of drive interfaces; and the spare solid-state drive has a capacity smaller than the plurality of component solid-state drives. 5 . The solid-state drive of claim 4 , wherein the plurality of component solid-state drives store at least one data set that has no replica in the spare solid-state drive.

6. The solid-state drive of claim 5 , wherein the drive aggregator is configured to receive commands in the at least one host interface and implement the commands using the plurality of component solid-state drives; and each of the plurality of component solid-state drives has a controller capable of processing commands from a host system. 7 . The solid-state drive of claim 6 , wherein each of the plurality of the component solid-state drives and the spare solid-state drive is packaged in an integrated circuit package having a ball grid array (BGA) form factor.

8. The solid state drive of claim 7, wherein the data set is identified based on a namespace.

9. The solid-state drive of claim 8, wherein following the failure of the component solid-state drive, the drive aggregator is configured to select a replacement component solid-state drive from the plurality of component solid-state drives and to rebuild the data set in the replacement component solid-state drive.

10. The solid-state drive of claim 9, wherein the drive aggregator is configured to mirror data change operations for the data set in the component solid-state drive and in the spare solid-state drive, while not mirroring non-data change operations performed in the component solid-state drive for the data set.

11. A method comprising: providing a solid-state drive having a plurality of component solid-state drives, a spare solid-state drive, and a drive aggregator, wherein the spare solid-state drive has a storage capacity less than any of the plurality of component solid-state drives; receiving, in the drive aggregator via at least one host interface, a command to operate a memory unit identified via a logical address; shielding the plurality of component solid-state drives and the spare solid-state drive from direct access by a host system by virtualizing an aggregate capacity of the plurality of component solid-state drives and the spare solid-state drive as a combined capacity of the solid-state drives, wherein the host system accesses the combined capacity based on transmitting commands addressed to the solid-state drives; implementing, by the drive aggregator, the command via transmitting the command to the component solid-state drives; maintaining, by the drive aggregator, in the spare solid-state drive, a copy of a data set stored in a first component solid-state drive of the plurality of component solid-state drives; reserving a portion of the storage capacity of the spare solid-state drive until the first component solid-state drive fails; as well as In response to the failure of the first component solid-state drive, a function of the first component solid-state drive relative to the data set is replaced with a corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

12. The method according to claim 11, further comprising: storing a failover setting identifying an association of the data set with the first component solid-state drive and the spare solid-state drive; as well as In response to the failure of the first component solid-state drive, an association between the data set and the first component solid-state drive is removed from the failover setting. The method of claim 12 , wherein the data set is identified via a namespace.

14. The method of claim 13, further comprising, following the failure of the first component solid state drive: identifying a second component solid-state drive among the plurality of component solid-state drives; and The data set is rebuilt in the second component solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

15. The method according to claim 14, further comprising: After rebuilding the data set in the second component solid-state drive, the failover setting is updated to include an association between the data set and the second component solid-state drive. 16 . The method of claim 15 , wherein each of the plurality of component solid state drives and the spare solid state drive is a ball grid array (BGA) solid state drive.

17. The method of claim 16, wherein the data set is identified via a region of a logical address defined in a capacity of the solid state drive and used in the command received in the at least one host interface.

18. A drive aggregator comprising: at least one host interface configured to receive commands from at least one host system; a plurality of drive interfaces configured to connect to a plurality of component solid-state drives; an interface configured to connect to a spare solid-state drive having a storage capacity less than any of the plurality of component solid-state drives; as well as translation logic coupled between the host interface, the plurality of drive interfaces, and the interface to the backup solid-state drive; wherein the translation logic is configured to maintain in the spare solid-state drive a copy of a data set stored in a first component solid-state drive of the plurality of component solid-state drives; wherein the drive aggregator is configured to retain a portion of the storage capacity until the first component solid-state drive fails; wherein the drive aggregator is configured to shield the plurality of component solid-state drives and the spare solid-state drive from direct access by a host system by virtualizing an aggregate capacity of the plurality of component solid-state drives and the spare solid-state drive as a combined capacity of the solid-state drives, wherein the host system accesses the combined capacity based on transmitting a command addressed to the solid-state drives; and Wherein in response to the failure of the first component solid-state drive, the translation is configured to replace a function of the first component solid-state drive relative to the data set with a corresponding function of the spare solid-state drive based on the copy of the data set maintained in the spare solid-state drive.

19. The drive aggregator of claim 18, further comprising: an integrated circuit package, wherein the at least one host interface, the translation logic, the plurality of drive interfaces, and the interface to the backup solid-state drive are packaged in the integrated circuit package; The translation logic comprises a field programmable gate array FPGA or an application specific integrated circuit ASIC; and The translation logic is configured to maintain the copy of the data set by identifying a first command to be executed in the first component solid-state drive for the data set, and issuing a corresponding second command to the spare solid-state drive in addition to issuing the first command to the first component solid-state drive.

20. The drive aggregator of claim 19, wherein following the failure of the first component solid-state drive, the translation logic is configured to reconstruct the data in a second component solid-state drive among the plurality of component solid-state drives while executing commands received in the at least one host interface and directed to the data set using the spare solid-state drive.

Images