Patent Description:
The construction and physical properties of solid-state memory devices, however, are very different from those of hard-disk drives. For example, solid-state memory devices are not organized based on the layout of a physical track or sectors which are laid out around a magnetic media disk of a hard-disk drive. As such, the legacy storage interfaces of most devices, which are designed to access data from the track and sector formats of a hard-disk drive, may have performance issues when accessing data stored in other types of memory. In the case of solid-state memory, attempting to access data through the legacy storage interface typically results in high read latency or damaging wear patterns when combined with the inherent write/erase cycles of solid-state memory operation. <CIT> relates to a storage processor which, rather than a storage pool, determines locations within the storage pool into which data from the host is to be stored by controlling striping across the SSDs of the storage pool. The storage system has a global view of data traffic of the overall system and is aware of what is going on with the overall system as opposed to the SSDs of the storage pool, which have comparatively limited view. An exemplary manner in which the storage system is capable of controlling addressing of the SSDs of the storage pool is by maintaining geometry information of the SSDs in the memory and maintaining virtual super blocks associated with the SSDs. The virtual super blocks are identified by SLBAs. Based on the flash geometry information, the CPU subsystem of the storage system dynamically binds the SLBAs of the virtual super blocks to physical super blocks. The bound SLBAs identify locations of the physical super blocks to which the SLBAs are bound. Similar to the virtual super blocks, the physical super blocks are made of physical blocks with each physical block having a physical pages. Similarly, virtual super blocks are each made of virtual blocks with each virtual block having virtual pages. Each of the virtual blocks corresponds to a physical block of a physical super block such that each of the virtual pages of the virtual block correspond to like physical pages of a physical block within the SSDs of the storage pool. At least some of the super physical blocks or at least some of the super virtual blocks span more than one SSD, therefore, the CPU subsystem can and does assign the host LBAs received from the host to the bound SLBAs and accordingly stripes across the physical super blocks while also causing striping across corresponding virtual super blocks. <NPL>, discusses an SSD-array level wear-leveling strategy called SWANS. SWANS dynamically monitors and balances write distributions across SSDs. <CIT> relates to a peripheral device which may implement storage virtualization for non-volatile storage devices connected to the peripheral device. A host system connected to the peripheral device may host one or multiple virtual machines. The peripheral device may implement different virtual interfaces for the virtual machines or the host system that present a storage partition at a non-volatile storage device to the virtual machine or host system for storage. Access requests from the virtual machines or host system are directed to the respective virtual interface at the peripheral device. The peripheral device may perform data encryption or decryption, or may perform throttling of access requests. The peripheral device may generate and send physical access requests to perform the access requests received via the virtual interfaces to the non-volatile storage devices. Completion of the access requests may be indicated to the virtual machines via the virtual interfaces. <CIT> proposes an approach that contemplates systems and methods to virtualize a physical NVMe controller associated with a computing device or host so that every virtual machine running on the host can have its own dedicated virtual NVMe controller. First, a plurality of virtual NVMe controllers are created on a single physical NVMe controller, which is associated with one or more storage devices. Once created, the plurality of virtual NVMe controllers are provided to VMs running on the host in place of the single physical NVMe controller attached to the host, and each of the virtual NVMe controllers organizes the storage units to be accessed by its corresponding VM as a logical volume. As a result, each of the VMs running on the host has its own namespace(s) and can access its storage devices directly through its own virtual NVMe controller.

It is the object of the present invention to enable an improved virtualization of isolation areas of solid state storage media.

The object is solved by the subject matter of the independent claims.

This summary is provided to introduce subject matter that is further described in the Detailed Description and Drawings. Accordingly, this Summary should not be considered to describe essential features nor used to limit the scope of the claimed subject matter.

The details of one or more implementations are set forth in the accompanying drawings and the following description.

The details of one or more implementations of virtualizing isolation areas of solid-state storage media are set forth in the accompanying figures and the detailed description below. In the figures, the left-most digit of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures indicates like elements:.

Conventional techniques that devices employ for accessing storage memory often rely on interface standards that were designed to access legacy types of storage based on magnetic or optical technologies. The construction and physical properties of solid-state memory, however, are very different from those of hard-disk drives, tape drives, or optical media (e.g., electromechanical storage media). For example, solid-state memory is not organized based on the layout of physical tracks or sectors on a media disk of a hard-disk drive or optical-disk drive. As such, legacy storage interfaces used by most computing devices, which are designed to sequentially access data in tracks or sectors, often have performance issues when accessing data stored in different types of memory media.

In the case of solid-state memory (e.g., NAND Flash memory), inherent side effects caused by write/erase cycles in the solid-state memory may significantly impact read latencies when reading data from the solid-state memory. Typically, solid-state memory drives do not provide visibility into or control of scheduling for when or where the write/erase cycles occur relative to read operations. Thus, the write/erase cycles of the solid-state memory may introduce latency issues with read operations that are delayed or interrupted by the conflicting write/erase cycles. This condition is particularly visible in multi-tenant systems, in which solid-state memory access activities of one initiator affects the performance of other initiators that attempt to access the same solid-state memory.

To address some of these shortcomings, interface standards are being defined that expose low-level information with respect to solid-state memory connectivity and structure that allow an initiator to manipulate access to the solid-state memory to improve access performance. Specifically, by knowing the topology of the solid-state memory, a system or initiator may directly control access of the solid-state memory to ensure traffic of different workloads, or different tenants, is isolated from that of the others. Directly controlling each of the initiators' access into the solid-state memory to provide isolation, however, places a large computational burden back onto the initiators themselves and the supporting host system. In particular, the initiators perform or manage all the activities that are typically handled by the internal solid-state drive controller, such as data routing, channel access, and maintaining a large number of physical memory areas. These low-level activities, when performed by the initiators or a host system, increase loading and overhead on the memory interconnect, host processing resources, system memory, and so on. Thus, having the initiators or host directly control the solid-state memory in order to implement storage isolation is not a cost- or resource-effective solution.

This disclosure describes apparatuses and techniques for virtualizing isolation areas of solid-state storage media. In contrast with conventional access techniques in which a host or initiators directly control all storage media activity, the described apparatuses and techniques may expose isolated units of storage to a host or tenants while offloading other low-level storage media functions from the host. For example, a storage media accelerator coupled between a host and solid-state drive (SSD) may expose virtualized isolation areas of storage to the host for traffic isolation and offload other low-level SSD functions, such as wear leveling, address mapping, and load balancing, to processing and memory resources of the accelerator (e.g., separate from the host compute resources). The storage media accelerator is also scalable, such that the storage media accelerator may manage one SSD or multiple SSDs, with each SSD having one or more virtualized areas of isolated storage (or units of storage) that may be exposed to a host or respective tenants.

Based on an exposed geometry or configuration of NAND of a SSD, the storage media accelerator may create storage "units" of isolation at any suitable granularity, such as an entire SSD, a NAND channel in a SSD, or a NAND device or NAND die on a NAND channel. Any physical isolation unit created by the storage media accelerator may be exposed to the host or tenants as a virtualized isolation unit or virtual unit of isolated storage. In some cases, the storage media accelerator maintains address mappings of the virtual storage units to physical areas of storage media and may also remap the physical isolation unit to another area of storage media transparently and without host involvement.

For example, the storage media accelerator may expose a NAND Channel A of a SSD as a virtual block of isolated NAND to a host. As part of a wear leveling or load balancing function, the storage media accelerator may migrate the virtual block of isolated NAND to Channel E on a same or another SSD without the host (e.g., initiator or tenant) being aware that the physical storage media behind the virtualized NAND block of isolation has been physically relocated. Thus, through the use of this virtualization, the storage media accelerator may remap virtual units of isolated storage dynamically to implement a coarse wear leveling across the solid-state memory devices of a drive, or redistribute highly accessed virtual units of isolated storage to completely different SSDs to implement performance-based load balancing without involving the host system.

In various aspects of virtualizing isolation areas of solid-state storage media, a storage media accelerator determines, via a storage media interface, a geometry of solid-state storage media that is coupled to the storage media interface. Based on the geometry of the solid-state storage media, the storage media accelerator selects an area of the solid-state storage media as an isolated unit of storage. The storage media accelerator maps a physical address of the isolated unit of storage to a virtual address through which the isolated unit of storage is accessible.

The storage media accelerator then exposes, via the virtual address, the isolated unit of storage through a host interface to enable host access of the isolated unit of storage in the solid-state storage media. The storage media accelerator may also remap the isolated unit of storage to other areas of the solid-state storage media without host interaction (e.g., notification, interruption, or use of host compute resources). By so doing, the storage media accelerator may provide isolation and partitioning functionalities to tenants (e.g., workloads or initiators) of the host, while efficiently handling lower-level storage media functions, such as wear leveling and load balancing, without host involvement or consumption of host computing resources.

The following discussion describes an operating environment, techniques that may be employed in the operating environment, and a System-on-Chip (SoC) in which components of the operating environment can be embodied. In the context of the present disclosure, reference is made to the operating environment by way of example only.

<FIG> illustrates an example operating environment <NUM> having a host device <NUM>, capable of storing or accessing various forms of data, files, objects, or information. Examples of a host device <NUM> may include a computing cluster <NUM> (e.g., of a cloud <NUM>), a server <NUM> or server hardware of a data center <NUM>, or a server <NUM> (e.g., standalone), any of which may be configured as part of a storage network, storage service, or cloud system. Further examples of host device <NUM> (not shown) may include a tablet computer, a set-top-box, a data storage appliance, wearable smart-device, television, content-streaming device, high-definition multimedia interface (HDMI) media stick, smart appliance, home automation controller, smart thermostat, Internet-of-Things (IoT) device, mobile-internet device (MID), a network-attached-storage (NAS) drive, aggregate storage system, server blade, gaming console, automotive entertainment device, automotive computing system, automotive control module (e.g., engine or power train control module), and so on. Generally, the host device <NUM> may communicate or store data for any suitable purpose, such as to enable functionalities of a particular type of device, provide a user interface, enable network access, implement gaming applications, playback media, provide navigation, edit content, provide data storage, or the like.

The host device <NUM> includes a processor <NUM> and computer-readable storage media <NUM>. The processor <NUM> may be implemented as any suitable type or number of processors (e.g., x86 or ARM), either single-core or multi-core, for executing instructions or commands of an operating system or other programs of the host device <NUM>. The computer-readable media <NUM> (CRM <NUM>) includes system memory <NUM> and storage media <NUM>. The system memory <NUM> of the host device <NUM> may include any suitable type or combination of volatile memory or non-volatile memory. For example, the volatile memory of host device <NUM> may include various types of random-access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM) or the like. The non-volatile memory may include read-only memory (ROM), electronically erasable programmable ROM (EEPROM) or Flash memory (e.g., NOR Flash or NAND Flash). These memories, individually or in combination, may store data associated with applications, tenants, workloads, initiators, virtual machines, and/or an operating system of host device <NUM>.

The storage media <NUM> of the host device <NUM> may be configured as any suitable type of data storage media, such as a storage device, storage drive, storage array, storage volume, or the like. Although described with reference to the host device <NUM>, the storage media <NUM> may also be implemented separately as a standalone device or as part of a larger storage collective, such as a data center, server farm, or virtualized storage system (e.g., for cloud-based storage or services). Examples of the storage media <NUM> include a hard-disk drive (HDD, not shown), an optical-disk drive (not shown), a solid-state drive <NUM> (SSD <NUM>), and/or an SSD array of SSDs <NUM>-<NUM> through <NUM>-n as shown in <FIG>, where n is any suitable integer or number of SSDs.

Each of the SSDs <NUM> includes or is formed from non-volatile memory devices <NUM> (NVM devices <NUM>) on which data or information of the host device <NUM> or other sources is stored. The NVM devices <NUM> may be implemented with any type or combination of solid-state memory media, such Flash, NAND Flash, NAND memory, RAM, DRAM (e.g., for caching), SRAM, or the like. In some cases, the data stored to the NVM devices <NUM> may be organized into files of data (e.g., content) or data objects that are stored to the SSDs <NUM> and accessed by the host device <NUM> or tenants, workloads, or initiators of the host device. The types, sizes, or formats of the files may vary depending on a respective source, use, or application associated with the file. For example, the files stored to the SSDs <NUM> may include audio files, video files, text files, image files, multimedia files, spreadsheets, and so on.

In this example, the host device <NUM> includes a storage media accelerator <NUM> (accelerator <NUM>) capable of implementing aspects of virtualizing isolation areas of solid-state storage media. The accelerator <NUM> includes a virtualizer <NUM>, address maps <NUM>, a wear leveler <NUM>, and a load balancer <NUM>, each of which may be implemented to perform respective operations or functions associated with virtualizing isolation areas of solid-state storage media. For example, the virtualizer <NUM> may determine a geometry of solid-state storage media and select, based on the geometry, an area of the solid-state storage media or an isolated unit of storage. The virtualizer <NUM> may then associate, in the address maps <NUM>, a physical address of area selected for the isolated unit of storage to a virtual address through which the isolated unit of storage is accessible. The isolated unit of storage is then exposed by the virtualizer <NUM>, via the virtual address, through a host interface to enable host access of the isolated unit of storage in the solid-state storage media.

In various aspects, the wear leveler <NUM> or load balancer <NUM> remaps the isolated unit of storage to other areas of the solid-state storage media without host interaction (e.g., notification, interruption, or use of host processing/memory resources). By so doing, the wear leveler <NUM> may dynamically implement a coarse wear leveling across the solid-state memory devices of a drive, or the load balancer <NUM> may redistribute highly accessed virtual units of isolated storage to completely different SSDs to implement performance-based load balancing without involving the host system. How these entities are implemented and used varies and is described throughout this disclosure.

The host device <NUM> may also include I/O ports <NUM>, a graphics processing unit <NUM> (GPU <NUM>), and data interfaces <NUM>. Generally, the I/O ports <NUM> allow a host device <NUM> to interact with other devices, peripherals, or users. For example, the I/O ports <NUM> may include or be coupled with a universal serial bus, human interface devices, audio inputs, audio outputs, or the like. The GPU <NUM> processes and renders graphics-related data for host device <NUM>, such as user interface elements of an operating system, applications, or the like. In some cases, the GPU <NUM> accesses a portion of local memory to render graphics or includes dedicated memory for rendering graphics (e.g., video RAM) of the host device <NUM>.

The data interfaces <NUM> of the host device <NUM> provide connectivity to one or more networks and other devices connected to those networks. The data interfaces <NUM> may include wired interfaces, such as Ethernet or fiber optic interfaces for communicating over a local network, intranet, or the Internet. Alternately or additionally, the data interfaces <NUM> may include wireless interfaces that facilitate communication over wireless networks, such as wireless LANs, wide-area wireless networks (e.g., cellular networks), and/or wireless personal-area-networks (WPANs). Any of the data communicated through the I/O ports <NUM> or the data interfaces <NUM> may be written to or read from the storage media <NUM> of the host device <NUM> in accordance with one or more aspects virtualizing isolation areas of solid-state storage media.

<FIG> illustrates example configurations of a storage media accelerator <NUM> and SSD <NUM> generally at <NUM>, which are implemented in accordance with one or more aspects of virtualizing isolation areas of solid-state storage media. In this example, the accelerator <NUM> is operably coupled between a host <NUM> and the SSD <NUM> from which virtualized areas of isolated storage are provided. The host <NUM> includes software <NUM>, such as applications, virtual machines, or tenants (not shown), that execute on compute resources <NUM> of the host. In some cases, the compute resources <NUM> include a combination of processing resources and system memory of the host <NUM> that are used to implement the applications, virtual machines, tenants, or initiators. The accelerator <NUM> may provide isolated access to virtualized units of storage to each virtual machine, tenant, or initiator, while offloading lower-level storage media functions from the compute resources <NUM>.

Generally, the tenants or initiators of the host <NUM> access data stored in the SSD <NUM> coupled to the accelerator <NUM>. In this example, the SSD <NUM> is implemented with an SSD controller <NUM> through which channels <NUM>-<NUM> through <NUM>-m of NAND are accessible. Each channel <NUM> of NAND (e.g., channel A or NAND channel <NUM>) includes multiple NAND devices <NUM>-<NUM> through <NUM>-n, which may be implemented as separate NAND devices or NAND dies of the SSD <NUM> that are accessible or addressable through a respective NAND channel <NUM>. In aspects of virtualizing isolation areas, the accelerator <NUM> may select any NAND device <NUM> or NAND channel <NUM> for virtualization. For example, the accelerator <NUM> may map a physical NAND device <NUM> to a virtual storage unit address in the address maps <NUM>. The virtual storage unit, or virtual unit of storage, is then exposed by the accelerator <NUM> to the host <NUM>, such as to a virtual machine or tenant application of the host <NUM>. By mapping an entire physical channel, device, or die of NAND memory to the virtual address, the accelerator <NUM> may provide isolated storage to the virtual machine or tenant that is isolated from other applications, virtual machines, initiators, or tenants of the host <NUM>.

<FIG> illustrates an example configuration of a storage media accelerator <NUM> and an array of n SSDs <NUM> generally at <NUM>, which are implemented in accordance with one or more aspects of virtualizing isolation areas of solid-state storage media. In this example, the accelerator <NUM> is operably coupled between a host <NUM> and an array of SSDs <NUM>-<NUM> through <NUM>-n from which virtualized areas of isolated storage are provided. The host <NUM> may be implemented as a multi-tenant host with virtual machines <NUM>, which may be implemented with any suitable number of virtual machines <NUM>-<NUM> through <NUM>-m. The virtual machines <NUM> execute from a hypervisor <NUM> that executes on the compute resources <NUM> of the host <NUM>. Alternately or additionally, the compute resources <NUM> may include a combination of processing resources and system memory of the host <NUM> that are used to implement the virtual machines <NUM> through which tenants or initiators operate. The accelerator <NUM> may provide isolated access to virtualized units of storage to each virtual machine <NUM>-<NUM> through <NUM>-m, tenant, or initiator, while offloading lower-level storage media functions from the compute resources <NUM> of the host <NUM>.

Generally, the virtual machines <NUM> of the host <NUM> access data stored in the array of SSDs <NUM> coupled to the accelerator <NUM>. In this example, each SSD <NUM> of the SSD array is implemented with an SSD controller <NUM> by which four channels <NUM> of NAND (e.g., A-D or E-H) are accessible. Each channel <NUM> of NAND (e.g., channel E or NAND channel <NUM>-<NUM>) includes multiple NAND devices or NAND dies. In aspects of virtualizing isolation areas, the accelerator <NUM> may select any SSD <NUM>, NAND channel <NUM>, or NAND devices as a storage area for virtualization. For example, the accelerator <NUM> may map SSD <NUM>-<NUM> to a virtual storage unit address in the address maps <NUM>. The virtual storage unit, or virtual unit of storage, is then exposed by the accelerator <NUM> to the host <NUM>, such as to a virtual machine <NUM> or tenant application of the host <NUM>. By mapping an entire SSD, physical channel, device, or die of NAND memory to the virtual address, the accelerator <NUM> may provide isolated storage to the virtual machine <NUM> or tenant that is isolated from other applications, virtual machines <NUM>, initiators, or tenants of the host <NUM>.

<FIG> illustrates an example configuration of a Fabric-enabled storage media accelerator generally at <NUM>, which is implemented in accordance with one or more aspects of virtualizing isolation areas of solid-state storage media. In this example, the accelerator <NUM> includes a Fabric interface (<NUM>) and is operably coupled between an instance of a Fabric <NUM> and an array of SSDs <NUM>-<NUM> through <NUM>-n. The Fabric interface <NUM> may include an NVM over Fabric (NVM-OF) interface, such as a Non-Volatile Memory Express (NVMe) over Ethernet, InfiniBand, or Fibre Channel (FC) interface. As such, the accelerator <NUM> may be implemented as a Fabric-enabled storage target in a disaggregated storage system.

Through the Fabric <NUM>, any of the multiple host devices <NUM>-<NUM> though <NUM>-m may access the SSD <NUM> array through the accelerator <NUM>. Here, each SSD <NUM> of the SSD array is implemented with an SSD controller <NUM> by which four channels <NUM> of NAND (e.g., A-D or E-H) are accessible. Each channel <NUM> of NAND (e.g., channel E or NAND channel <NUM>-<NUM>) includes multiple NAND devices or NAND dies. In aspects of virtualizing isolation areas, the accelerator <NUM> may select any SSD <NUM>, NAND channel <NUM>, or NAND devices as a storage area for virtualization. For example, the accelerator <NUM> may map SSD <NUM>-<NUM> to a virtual storage unit address in the address maps <NUM>. The virtual storage unit, or virtual unit of storage, is then exposed by the accelerator <NUM> to the host device <NUM>, such as to a virtual machine or tenant application of one of the host devices <NUM>. By mapping an entire SSD, physical channel, device, or die of NAND memory to the virtual address, the accelerator <NUM> may provide isolated storage to the virtual machine or tenant that is isolated from other host devices, applications, virtual machines, initiators, or tenants.

The following discussion describes techniques of virtualizing isolation areas of solid-state storage media, which may provide storage isolation and partition functionalities to a host while offloading lower-level storage media functions, such as wear leveling, load balancing, or the like, to a storage media accelerator. These techniques may be implemented using any of the environments and entities described herein, such as the accelerator <NUM>, virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, or load balancer <NUM>. These techniques include methods illustrated in <FIG>, <FIG>, <FIG>, and <FIG> each of which is shown as a set of operations performed by one or more entities.

These methods are not necessarily limited to the orders of operations shown in the associated figures. Rather, any of the operations may be repeated, skipped, substituted, or re-ordered to implement various aspects described herein. Further, these methods may be used in conjunction with one another, in whole or in part, whether performed by the same entity, separate entities, or any combination thereof. For example, the methods may be combined to expose virtualized isolation areas of storage media while transparently providing wear leveling, load balancing, or data migration without host interaction or involvement. In portions of the following discussion, reference will be made to the operating environment <NUM> of <FIG> and entities of <FIG>, <FIG>, and/or <FIG> by way of example. Such reference is not to be taken as limiting described aspects to the operating environment <NUM>, entities, or configurations, but rather as illustrative of one of a variety of examples. Alternately or additionally, operations of the methods may also be implemented by or with entities described with reference to the System-on-Chip of <FIG> and/or the storage media accelerator of <FIG>.

<FIG> depicts an example method <NUM> for virtualizing isolation areas of solid-state storage media, including operations performed by or with the accelerator <NUM>, virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, or load balancer <NUM>.

At <NUM>, an accelerator determines, via a storage interface, a geometry of solid-state storage media. The solid-state storage media may expose the geometry to the accelerator, such as through an open-channel SSD or project Denali compliant interface. In some cases, the geometry includes an architecture, topology, configuration, available control features, or other parameters of a drive in which the solid-state storage media is implemented. Alternately or additionally, the geometry of the solid-state storage media may include a logical geometry, a physical geometry, a number of channels, a number of logical units, a number of parallel units, a number of chunks, a chunk size, or a minimum write size of the solid-state storage media.

At <NUM>, the accelerator selects, based on the geometry of the solid-state media, an area of the solid-state storage media as an isolated unit of storage. The area selected as the isolated unit of storage may include any granularity or subdivision of solid-state storage, such as an entire SSD, a memory channel of a SSD, a memory device of a SSD, or a memory die of a SSD.

At <NUM>, the accelerator maps a physical address of the area selected for the isolated unit of storage to a virtual address through which the isolated unit of storage is accessible. The accelerator may maintain this mapping, as well as other mappings of physical to virtual addresses for isolated units of storage. By so doing, the address mapping function can be offloaded from a host or handled by the accelerator outside of a SSD or SSD controller.

At <NUM>, the accelerator exposes, via the virtual address, the isolated unit of storage through a host interface to enable host access of the isolated unit of storage in the solid-state storage media. In some cases, the isolated unit of storage is associated with an initiator, a workload, a virtual machine, or a tenant of the host. In such cases, the isolated unit of storage is isolated from another initiator, another workload, another virtual machine, or another tenant of the host. Alternately or additionally, the solid-state storage media may be configured as nearline or direct attached storage of a host device.

Optionally at <NUM>, the accelerator alters the physical address to which the virtual address of the isolated unit of storage is mapped. This may be effective to remap the isolated unit of storage to a different area of the solid-state storage media. In some cases, the physical address is remapped to another area of a SSD as part of a wear leveling function or algorithm. In other cases, the physical address is remapped to another SSD as part of a load balancing function or algorithm implemented by the accelerator.

<FIG> depicts an example method <NUM> for remapping an isolated unit of storage to another area of storage media in a SSD. The operations of method <NUM> may be performed by or with the accelerator <NUM>, virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, or load balancer <NUM>.

At <NUM>, an accelerator exposes, via respective virtual addresses, one or more isolated units of storage of a SSD to a host through a host interface. The virtualized isolated units of storage may correspond to a NAND channel of a SSD, a NAND device of a SSD, or a NAND die of a SSD. By way of example, consider <FIG> in which NAND channel A is exposed to the host device as a unit of isolated storage. A tenant or workload of the host device may access the NAND channel A as isolated storage without conflicting traffic from other tenants or initiators.

At <NUM>, the accelerator monitors use of areas of storage media in the SSD that correspond to the one or more isolated units of storage of the SSD. In some cases, a wear leveler of the accelerator monitors use or access of NAND channels, NAND devices, or NAND dies of the SSD to which the isolated units of storage correspond. In the context of the present example, assume the tenant of the host device accesses NAND channel A more than other areas of the SSD are accessed.

At <NUM>, the accelerator selects, based on the monitored use, one of the isolated units of storage for remapping to another area of storage media in the SSD. For example, the accelerator may select an isolated unit of storage that corresponds to a heavily a used NAND channel, NAND device, of NAND die of the SSD for remapping. As described herein, the accelerator may remap virtualized isolation areas without host interaction or use of host resources. Continuing the ongoing example, the accelerator selects NAND channel A for remapping to another area of the SSD.

At <NUM>, the accelerator remaps a physical address of the another area of storage media to the respective virtual address of the isolated unit of storage. By remapping the virtual address of the isolated unit of storage, the accelerator may dynamically implement wear leveling by redirecting access to the another area of storage media. In the context of the present example in <FIG>, the accelerator remaps a physical address for the tenant's isolated unit of storage from NAND channel A to NAND channel D of the SSD.

At <NUM>, the accelerator exposes, via the respective virtual address, the remapped isolated unit of storage to the host through the host interface. This may be effective to enable host access to the another area of storage media in the SSD through the virtual address of the isolated unit of storage. Due to the virtual addressing of the isolated unit of storage, the remapping is transparent to the host or tenant, and also requires no host interaction or resources due to offloading provided by the accelerator. Concluding the present example, the accelerator migrates data from NAND channel A to NAND channel D in the SSD and redirects, via the virtual address, access by the tenant of the host device to NAND channel D for subsequent data access.

Optionally at <NUM>, the accelerator erases the area of storage media in the SSD to which the virtual address of the remapped isolated unit of storage was previously mapped. This may be effective to free the area of storage media for reallocation or reuse with another isolated unit of storage in the SSD.

<FIG> depicts an example method <NUM> for remapping an isolated unit of storage to another SSD, including operations performed by or with the accelerator <NUM>, virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, or load balancer <NUM>.

At <NUM>, an accelerator exposes, via respective virtual addresses, one or more isolated units of storage in solid-state storage media to a host through a host interface. The virtualized isolated units of storage may correspond to a SSD, a NAND channel of a SSD, a NAND device of a SSD, or a NAND die of a SSD. By way of example, consider <FIG> in which NAND channel A of a first SSD of a SSD array is exposed to the host device as a unit of isolated storage. A tenant or workload of the host device may access the NAND channel A as isolated storage without conflicting traffic from other tenants or initiators.

At <NUM>, the accelerator monitors use of areas of storage media in the solid-state storage media that correspond to the one or more isolated units of storage. In some cases, a load balancer of the accelerator monitors use or access between SSDs or respective areas of SSDs to which the isolated units of storage correspond. In the context of the present example, assume the tenant of the host device accesses NAND channel A of the SSD <NUM>-<NUM> more than other SSDs in the array are accessed.

At <NUM>, the accelerator selects, based on the monitored use, one of the isolated units of storage for remapping to another area of storage media in the solid-state storage media. For example, the accelerator may select an isolated unit of storage that corresponds to a heavily used or accessed SSD for remapping. As described herein, the accelerator may remap virtualized isolation areas to different SSDs without host interaction or use of host resources. Continuing the ongoing example, the accelerator selects SSD <NUM>-<NUM> for remapping to another SSD of the array.

At <NUM>, the accelerator remaps a physical address of the another area of storage media to the respective virtual address of the isolated unit of storage. By remapping the virtual address of the isolated unit of storage, the accelerator may dynamically implement load balancing by redirecting access to the another area of storage media. In the context of the present example in <FIG>, the accelerator remaps a physical address for the tenant's isolated unit of storage from NAND channel A of SSD <NUM>-<NUM> to NAND channel E of the SSD <NUM>-n in the array.

At <NUM>, the accelerator exposes, via the respective virtual address, the remapped isolated unit of storage to the host through the host interface. This may be effective to enable host access to the another area of storage media in the solid-state storage media through the virtual address of the isolated unit of storage. Concluding the present example, the accelerator migrates data from NAND channel A of SSD <NUM>-<NUM> to NAND channel E of SSD <NUM>-n and redirects, via the virtual address, access by the tenant of the host device from SSD <NUM>-<NUM> to SSD <NUM>-n for subsequent data access.

Optionally at <NUM>, the accelerator erases the area of storage media in the solid-state storage media to which the virtual address of the remapped isolated unit of storage was previously mapped. This may be effective to free the area of storage media for reallocation or reuse with another isolated unit of storage in the solid-state storage media. For example, the accelerator may erase a SSD, a NAND channel, a NAND device, or a NAND die of data to clear the storage area.

<FIG> depicts an example method <NUM> for migrating data of a virtualized isolation area from a source area of storage media to a destination area of storage media. The operations of method <NUM> may be performed by or with the accelerator <NUM>, virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, or load balancer <NUM>.

At <NUM>, an accelerator selects a destination area of solid-state storage media for remapping an isolated unit of storage. The destination area may include an entire SSD, a NAND channel of a SSD, or a NAND device of a SSD.

At <NUM>, the accelerator copies, to the destination area, data from a source area of solid-state storage media to which a virtual address of the isolated unit of storage is mapped. At <NUM>, the accelerator directs, via the virtual address of the isolated unit of storage, host access to the source area of the solid-state storage media while at least some of the data is copied. For example, the accelerator may copy data from an active isolation unit of storage to a spare unit while at least some read/write access continues to be directed to the active isolation unit of storage.

At <NUM>, the accelerator mirrors host access of the source area to the destination area for access of data that is below a watermark of synchronized data. In other words, new writes to the active isolation unit that are directed below a watermark of data already copied to the spare isolation unit may be mirrored to both units for data coherency during the migration.

At <NUM>, the accelerator directs, via the virtual address of the isolated unit of storage, host access to the destination area of the solid-state storage media. Responsive to synchronization between the active isolation unit of storage and the destination area, the accelerator may redirect access made through the virtual address to the new unit of storage where the copied data resides. Optionally at <NUM>, the accelerator erases the data from the source area of the solid-state media to free the source area.

<FIG> illustrates an exemplary System-on-Chip (SoC) <NUM> that may implement various aspects of virtualizing isolation areas of solid-state storage media. The SoC <NUM> may be implemented in any suitable device, such as a computing device, host device, network-attached storage, smart appliance, printer, set-top box, server, data center, solid-state drive (SSD), storage drive array, memory module, automotive computing system, server, server blade, storage blade, storage backplane, storage media expansion device, storage media card, storage media adapter, network attached storage, Fabric-enabled storage target, NVMe-based storage controller, or any other suitable type of device (e.g., others described herein). Although described with reference to a SoC, the entities of <FIG> may also be implemented as other types of integrated circuits or embedded systems, such as an application-specific integrated-circuit (ASIC), storage controller card, storage backplane, storage controller, communication controller, application-specific standard product (ASSP), digital signal processor (DSP), programmable SoC (PSoC), system-in-package (SiP), or field-programmable gate array (FPGA).

The SoC <NUM> may be integrated with electronic circuitry, a microprocessor, memory, input-output (I/O) control logic, communication interfaces, firmware, and/or software useful to provide functionalities of a host device or storage system, such as any of the devices or components described herein (e.g., storage drive or storage array). The SoC <NUM> may also include an integrated data bus or interconnect fabric (not shown) that couples the various components of the SoC for data communication or routing between the components. The integrated data bus, interconnect fabric, or other components of the SoC <NUM> may be exposed or accessed through an external port, parallel data interface, serial data interface, peripheral component interface, or any other suitable data interface. For example, the components the SoC <NUM> may access or control external storage media through an external interface or off-chip data interface.

In this example, the SoC <NUM> includes various components such as input-output (I/O) control logic <NUM> and a hardware-based processor <NUM> (processor <NUM>), such as a microprocessor, processor core, application processor, DSP, or the like (e.g., processing resource separate from a host x86 processor). The SoC <NUM> also includes memory <NUM>, which may include any type and/or combination of RAM, SRAM, DRAM, non-volatile memory, ROM, one-time programmable (OTP) memory, multiple-time programmable (MTP) memory, Flash memory, and/or other suitable electronic data storage. In some aspects, the processor <NUM> and code stored on the memory <NUM> are implemented as a storage media accelerator or accelerator-enabled storage aggregator to provide various functionalities associated with virtualizing isolation areas of solid-state storage media. In the context of this disclosure, the memory <NUM> stores data, code, instructions, or other information via non-transitory signals, and does not include carrier waves or transitory signals. Alternately or additionally, SoC <NUM> may comprise a data interface (not shown) for accessing additional or expandable off-chip storage media, such as magnetic memory or solid-state memory (e.g., Flash or NAND memory).

The SoC <NUM> may also include firmware <NUM>, applications, programs, software, and/or operating systems, which may be embodied as processor-executable instructions maintained on the memory <NUM> for execution by the processor <NUM> to implement functionalities of the SoC <NUM>. The SoC <NUM> may also include other communication interfaces, such as a transceiver interface for controlling or communicating with components of a local on-chip (not shown) or off-chip communication transceiver. Alternately or additionally, the transceiver interface may also include or implement a signal interface to communicate radio frequency (RF), intermediate frequency (IF), or baseband frequency signals off-chip to facilitate wired or wireless communication through transceivers, physical layer transceivers (PHYs), or media access controllers (MACs) coupled to the SoC <NUM>. For example, the SoC <NUM> may include a transceiver interface configured to enable storage over a wired or wireless network, such as to provide a network attached storage (NAS) volume with virtualized storage isolation features.

The SoC <NUM> also includes an accelerator <NUM> with a virtualizer <NUM>, address maps <NUM>, wear leveler <NUM>, and load balancer <NUM>, which may be implemented separately as shown or combined with a storage component or data interface. In accordance with various aspects of virtualizing isolation areas of solid-state storage media, the accelerator <NUM> may expose virtualized units of storage to a host or tenants and offload other storage media management functions to the processor <NUM> of the accelerator, such as wear leveling, load balancing, or the like. Alternately or additionally, the address maps <NUM> may be stored on the memory <NUM> of the SoC <NUM> or on a memory operably coupled with the SoC <NUM> and accessible to the accelerator <NUM>.

Any of these entities may be embodied as disparate or combined components, as described with reference to various aspects presented herein. Examples of these components and/or entities, or corresponding functionality, are described with reference to the respective components or entities of the environment <NUM> of <FIG> or respective configurations illustrated in <FIG>, <FIG>, and/or <FIG>. The accelerator <NUM>, either in whole or part, may be implemented as processor-executable instructions maintained by the memory <NUM> and executed by the processor <NUM> to implement various aspects and/or features of virtualizing isolation areas of solid-state storage media.

The accelerator <NUM>, may be implemented independently or in combination with any suitable component or circuitry to implement aspects described herein. For example, accelerator <NUM> may be implemented as part of a DSP, processor/storage bridge, I/O bridge, graphics processing unit, memory controller, storage controller, arithmetic logic unit (ALD), or the like. The accelerator <NUM> may also be provided integrally with other entities of SoC <NUM>, such as integrated with the processor <NUM>, memory <NUM>, a host interface, a storage media interface, or firmware <NUM> of the SoC <NUM>. Alternately or additionally, the accelerator <NUM>, virtualizer <NUM>, wear leveler <NUM>, load balancer <NUM>, and/or other components of the SoC <NUM> may be implemented as hardware, firmware, fixed logic circuitry, or any combination thereof.

As another example, consider <FIG> which illustrates an example storage media accelerator <NUM> in accordance with one or more aspects of virtualizing isolation areas of solid-state storage media. In various aspects, the storage media accelerator <NUM> or any combination of components thereof may be implemented as a storage drive controller, storage media controller, NAS controller, Fabric interface, NVMe initiator, NVMe target, or a storage aggregation controller for solid-state storage media. In some cases, the storage media accelerator <NUM> is implemented similar to or with components of the SoC <NUM> as described with reference to <FIG>. In other words, an instance of the SoC <NUM> may be configured as a storage media accelerator, such as the storage media accelerator <NUM> to provide and manage virtualized isolation areas of solid-state media.

In this example, the storage media accelerator <NUM> includes input-output (I/O) control logic <NUM> and a processor <NUM>, such as a microprocessor, processor core, application processor, DSP, or the like. In some aspects, the processor <NUM> and firmware of the storage media accelerator <NUM> may be implemented to provide various functionalities associated with virtualizing isolation areas of solid-state storage media, such as those described with reference to methods <NUM>, <NUM>, <NUM>, and/or <NUM>. The storage media accelerator also includes a storage media interface <NUM> and a host interface <NUM>, which enable access to storage media and host system, respectively. The storage media interface <NUM> may include a physical page addressing (PPA) interface, peripheral component interconnect express (PCIe) interface, non-volatile memory express (NVMe) interface, NVM over Fabric (NVM-OF) interface, NVM host controller interface specification (NVMHCIS) compliant interface, or the like. Alternately or additionally, the host interface may include a PCIe interface, SATA-based interface, NVMe interface, NVM-OF interface, NVMHCIS compliant interface, Fabric-enabled storage interface, or the like.

In this example, the storage media accelerator <NUM> includes a flash translation layer <NUM> (FTL <NUM>) and a garbage collector <NUM>. In some aspects of virtualizing isolation areas solid-state storage media, the storage media accelerator <NUM> includes a host-side or non-drive-side FTL <NUM> (e.g., pBLK layer for open-channel SSDs) and/or garbage collector <NUM> for managing access of storage media of SSDs that are operably coupled with the accelerator. For example, the FTL <NUM> may include a log manager for managing sequential write streams (e.g., write buffering), maintaining address maps of storage media, and implementing or coordinating garbage collection or media reuse with the garbage collector <NUM>. Alternately or additionally, the FTL <NUM> may include a media management module for wear leveling, error correction coding, read-retry, bad-block management, metadata recovery, or the like. As such, these SSD functionalities may also be implemented by or offloaded to the storage media accelerator <NUM>.

Claim 1:
A method for virtualizing isolation areas of solid-state storage media, wherein the method is performed by a storage media accelerator coupled to a host interface, the method comprising:
determining, via a storage media interface provided by the storage media accelerator, a geometry of a solid-state storage media drive coupled to the storage media interface, the geometry comprising multiple channels of solid-state storage media of the solid-state storage media drive, each of the multiple channels enabling access to respective solid-state storage media dies of the solid-state storage media drive that are coupled to the channel of solid-state storage media;
selecting, based on the geometry of the solid-state storage media drive, one of the multiple channels of solid-state storage media of the solid-state storage media drive as an isolated unit of storage, the isolated unit of storage comprising all of the respective solid-state storage media dies coupled to the channel of solid-state storage media of the solid-state storage media drive;
mapping a physical address of the isolated unit of storage that comprises the channel of solid-state storage media to a virtual address through which the isolated unit of storage is accessible;
characterized in that the method further comprises:
exposing, via the virtual address, the isolated unit of storage through the host interface to enable an initiator executing on a host to access the respective solid-state storage media dies of the channel of solid-state storage media as the isolated unit of storage in the solid-state storage media drive,
wherein all of the respective solid-state storage media dies of the channel of solid-state storage media that form the isolated unit of storage are isolated from memory traffic from other tenants executing on the host.