Automated recreation of missing storage volumes

By utilizing NvRAM to store volume metadata after the persistent loss of SCM devices, the SCM volume is automatically recreated and reallocated, solving the problem of long manual recovery time in the prior art and achieving fast and automatic system recovery.

CN116806332BActive Publication Date: 2026-05-12INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
INTERNATIONAL BUSINESS MACHINE CORPORATION
Filing Date
2022-01-11
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

In the prior art, after persistent loss, the manual re-creation and reallocation of volumes in storage class memory (SCM) devices takes too long, and data loss may lead to difficulties in system recovery.

Method used

Utilize more non-volatile storage devices such as NVRAM to store volume metadata for SCM devices, and automatically recreate and reallocate SCM volumes after persistent loss, achieving automatic configuration through request management software.

Benefits of technology

It reduces the time spent manually recreating volumes, improves system recovery efficiency, and ensures automatic restoration to the original configuration after data loss.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116806332B_ABST
    Figure CN116806332B_ABST
Patent Text Reader

Abstract

A computing device, non-transitory computer-readable storage medium, and method for automatically recreating a lost storage volume are provided. A volume command including volume metadata associated with a storage volume of an SCM storage device is received. The volume metadata is stored in another storage device that is more non-volatile than the SCM storage device. The storage volume is configured in accordance with the volume command, including forwarding the volume command to an SCM device driver. After forwarding the volume command, a notification of a persistent loss at the SCM storage device is received. After receiving the notification of the persistent loss, the volume metadata is retrieved from the other storage device. The storage volume is automatically reconfigured in accordance with the volume command, including submitting the retrieved volume metadata to the SCM device driver.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure generally relates to storage devices, and more specifically, to systems and methods for automatically recreating lost storage volumes. Background Technology

[0002] Various intermediate storage solutions, including storage-class memory (SCM), are designed to address the cost / performance tradeoff between dynamic random access memory (DRAM) and flash memory. Typically, these intermediate storage solutions use low-latency transfer techniques and are accessed / used like RAM in a computer system. For example, portions of an intermediate storage solution can be directly mapped into memory, facilitating regular CPU read / write cycles (i.e., as part of the main page table). Advantageously, intermediate storage solutions are persistent. This allows systems using intermediate storage solutions to reboot / restart more quickly (e.g., compared to flash memory), typically retaining the memory contents. Summary of the Invention

[0003] According to various embodiments of this disclosure, a computing device, a non-transitory computer-readable storage medium, and a method for automatically recreating a lost storage volume are provided.

[0004] (For example, from a program or user via a user interface) a volume command is received, which includes volume metadata associated with a storage volume of a storage-class memory (SCM) storage device. The volume metadata is stored on another storage device that is less prone to loss than the SCM storage device. The storage volume is configured according to the volume command, which includes forwarding the volume command to the SCM device driver.

[0005] After forwarding the volume command, receive notification of persistent data loss at the SCM storage device. Upon notification of persistent data loss at the SCM storage device, retrieve the stored volume metadata from another storage device. Automatically reconfigure the storage volume according to the volume command, including submitting the retrieved volume metadata to the SCM device driver.

[0006] These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which is taken in conjunction with the accompanying drawings. Attached Figure Description

[0007] The accompanying drawings are illustrative embodiments. They do not show all embodiments. Other embodiments may be used alternatively or in addition. Details that may be obvious or unnecessary may be omitted to save space or for more efficient description. Some embodiments may be implemented with additional components or steps and / or without all components or steps shown. When the same reference numerals appear in different drawings, they refer to the same or similar components or steps.

[0008] Figure 1An exemplary computer architecture is shown that facilitates the automatic regeneration of lost storage volumes.

[0009] Figure 2 A flowchart is shown as an exemplary method for automatically recreating a lost storage volume.

[0010] Figure 3 The computer hardware platform with the specific configuration is shown. Detailed Implementation

[0011] In the following detailed embodiments, numerous specific details are illustrated by example to provide a thorough understanding of the teachings. However, it will be apparent that these teachings can be practiced without these details. In other instances, well-known methods, processes, components, and / or circuits have been described at a relatively high level without detail to avoid unnecessarily obscuring aspects of these teachings.

[0012] This disclosure generally relates to systems and methods for automatically recreating lost storage volumes. With the aid of the concepts discussed herein, volumes at a storage device can be automatically (re)created / (re)configured after persistent loss at the storage device.

[0013] Storage-class storage (SCM) and other intermediate storage solutions have varying degrees of stability and may not maintain persistence under certain conditions. When this happens, (potentially all) data on the device may be lost. Data loss can include, for example, the erasure of the (SCM) volume and its corresponding volume metadata. SCM devices can include a large number of volumes (e.g., hundreds or thousands). Manually recreating the volumes and reallocating them back to their partitions (e.g., virtual machines) is time-consuming. In contrast, when an intermediate storage solution, such as an SCM storage solution, loses persistence, the volumes of the intermediate storage solution are automatically recreated.

[0014] To facilitate volume re-creation, an alternative storage solution that is less volatile (i.e., more stable) than the intermediate storage solution is utilized. In one example, non-volatile random access memory (NvRAM) is used. However, in practice, any less volatile (i.e., more stable) storage solution can be used, including any type of flash memory.

[0015] When volumes are created or modified in an intermediate storage solution, the corresponding volume metadata is stored in another (more durable and stable) storage solution. In the event of persistent data loss, the stored metadata can be retrieved and used to automatically recreate the volumes on the intermediate storage solution and reassign these volumes to the previous partitions (e.g., virtual machines) that owned them. Users or administrators do not need to worry about remembering and recreating previous (e.g., SCM) volume configurations. Therefore, automatic volume recreation and reassignment can save significant time compared to manually recreating and reassigning volumes.

[0016] In a more specific example, a request to create, modify, or destroy an SCM volume at the SCM device is created via the user interface and passed down to the request management software. This request may include volume metadata, such as a volume ID (e.g., a Universally Unique Identifier (UUID)), volume name, volume location, volume size, and the partition that owns the volume (e.g., a virtual machine). The request management software accesses (e.g., retrieves) the volume metadata from this request and stores it in a more non-volatile storage device, such as NVRAM. The request management software can continuously update the volume metadata as users or administrators change the SCM volume configuration.

[0017] After storing the volume metadata associated with the request, the request manager can forward the request to the SCM device driver to perform the requested action (create volume, modify volume, destroy volume, etc.) at the SCM device. If the SCM device loses persistence, or when the SCM device loses persistence, the SCM device driver will notify the request management software of the loss. In response to this notification, the request manager parses the previously stored volume metadata. Using the stored volume metadata, the request management software can automatically create / copy one or more requests. The request management software can send one or more requests to the SCM device driver. The SCM device driver can fulfill one or more requests to recreate and reallocate volumes, including converting the SCM device back to its configuration before the loss of persistence.

[0018] Therefore, using the stored volume metadata, the request management software can automatically recreate the lost SCM volumes and automatically reassign them to partitions (e.g., virtual machines) that previously owned them. Aspects of this invention are applicable to various SCM storage solutions, including: non-volatile dual in-line memory modules (NvDIMM), Intel Optane, 3DXpoint, resistive RAM (RRAM or ReRAM), magnetoresistive RAM (MRAM), spin-transfer torque MRAM (STT-MRAM), nanotube RAM, etc.

[0019] The aspects of this disclosure generally also apply to other combinations of storage solutions. Metadata associated with a more volatile (less stable) storage device can be stored on a less volatile (more stable) storage device. The stored metadata can be retrieved from the less volatile storage device and used to automatically (re)configure volumes on the more volatile storage device in response to persistent loss on the more volatile storage device. The volatility of a storage device can be considered to be related to the frequency and / or conditions under which the storage device may lose persistence. A storage device that loses persistence more frequently and / or under more conditions can be considered more volatile (or less stable) than a storage device that loses persistence less frequently and / or under fewer conditions. On the other hand, a storage device that loses persistence less frequently and / or under fewer conditions can be considered less volatile (or more stable) than a storage device that loses persistence less frequently and / or under more conditions.

[0020] In this specification and the appended claims, a "partition" is defined as a group of interoperable computing resources allocated to perform functions. Different types of resources, such as processors, memory, networks, storage, etc., can be allocated to partitions. In this specification and the appended claims, a partition may also be referred to as a "virtual machine." When computing resources are allocated to a partition or a virtual machine, the partition or virtual machine can be considered to "own" the computing resources. For example, a partition or virtual machine can "own" a storage volume.

[0021] To better understand the features of this disclosure, it may be helpful to discuss exemplary architectures. Therefore, Figure 1 An exemplary computer architecture 100 is shown that facilitates the automatic regeneration of lost storage volumes.

[0022] Exemplary Architecture

[0023] Now for reference Figure 1 This is an exemplary computer architecture 100 consistent with the illustrative embodiments, facilitating the automatic regeneration of lost storage volumes. Architecture 100 includes a storage device manager 101, a storage device 102, a device driver 103, an SCM device 104, a program 106, and a user interface 107. Compared to the SCM device 104, the storage device 102 (e.g., NvRAM) can be a more non-volatile (more stable) storage solution.

[0024] Typically, program 106 or a user can send volume commands via user interface 107 to change the volume configuration at SCM device 104. Volume commands can be directed to device driver 103. As depicted, storage device manager 101 is located between program 106 / user interface 107 and device driver 103. Storage device manager 101 can receive volume commands before device driver 103.

[0025] Storage device manager 101 can extract metadata included in a volume command and store the metadata in storage device 102. Storage manager 101 can then forward the volume command (including metadata) to device driver 103. Device driver 103 can then implement volume configuration changes at SMC device 104 based on the volume command and the included metadata.

[0026] After a configuration change is implemented, SCM device 104 may lose persistence. Persistence can be lost for various reasons, including firmware errors, hardware errors, sudden power outages, capacitor discharge before data is saved, error correction code (ECC) failures, etc. Device driver 103 can detect the loss of persistence at SCM device 104 and notify storage device manager 101 of the loss of persistence.

[0027] In response to a persistent data loss notification, storage device manager 101 can access extracted metadata from storage device 102. Storage device manager 101 can automatically generate (previously received) volume commands (or another similar volume command) and / or automatically generate (previously received) volume commands (or another similar volume command) including the extracted metadata from the extracted metadata. Storage device manager 101 can send the automatically generated volume commands to device drive 103. Device drive 103 can implement another volume configuration change at SMC device 104 based on the automatically generated volume commands and extracted metadata. Implementing another volume configuration change causes SMC device 104 to revert to a volume configuration that matches the volume configuration prior to the persistent data loss.

[0028] Figure 2 A flowchart is shown for an exemplary method 200 for automatically recreating a lost storage volume. Method 200 will be described with reference to components of computer architecture 100.

[0029] Method 200 includes receiving a volume command (201) that includes volume metadata associated with a storage volume on the SCM storage device. For example, storage device manager 101 may receive a command 111 that includes metadata 112 from program 106 or user interface 107. Metadata 112 may include one or more of the following, such as: volume ID (e.g., a universally unique identifier (UUID)) at SCM device 104, volume name at SCM device 104, volume location at SCM device 104, volume size at SCM device 104, partition (virtual machine) that owns the volume at SCM device 104, etc.

[0030] Method 200 includes storing volume metadata on another storage device that is less prone to loss than the SCM storage device (202). For example, storage device manager 101 can retrieve metadata 112 from command 111 and store metadata 112 in storage device 102.

[0031] Method 200 includes configuring a storage volume based on volume commands, including forwarding volume commands to an SCM device driver (203). For example, a storage device manager 101 may send a command 111, including metadata 112, to a device driver 103. The device driver 103 may receive the command 111, including metadata 112, from the storage device manager 101. The device driver 103 may configure the storage volume at the SCM device 104 based on the command 111 and the metadata 112. For example, the device driver 103 may specify a configuration 116 based on the command 111 and the metadata 112. The device driver 103 may implement the configuration 116 at the SCM device 104, including one or more of the following: volume creation, volume modification (e.g., resizing, changing location, etc.), volume corruption, allocating the volume to a partition (virtual machine), etc.

[0032] After configuration 116 is implemented, SCM device 104 can operate as expected and according to command 111 and metadata 112 for a certain period of time. At some point or even later, SCM device 104 may lose persistence (represented by persistence loss 117) due to one or more of the following: firmware errors, hardware errors, sudden power outages, capacitor discharge before data is saved, error correction code (ECC) failures, etc. at or associated with SCM device 104.

[0033] Method 200 includes receiving a notification of persistent loss at the SCM storage device (204) after a forward volume command. For example, device driver 103 may detect persistent loss 117 at SCM device 104. Device driver 103 may notify storage device manager 101 of persistent loss 117. Alternatively, storage device manager 101 may detect persistent loss 117 directly.

[0034] Method 200 includes retrieving volume metadata (205) from another storage device after receiving a notification of persistent loss. For example, after being notified (or detected) of persistent loss 117, storage device manager 101 may submit query 113 to storage device 102. Query 113 may be a query for metadata associated with SCM device 104. In response to query 113, storage device 102 may return metadata 112 to storage device manager 101.

[0035] Method 200 includes automatically reconfiguring the storage volume based on volume commands, including submitting the acquired volume metadata to the SCM device driver (206). For example, the storage device manager 101 can automatically generate command 114 from metadata 112 and automatically generate command 114 including metadata 112. Command 114 can be similar to (if not completely copied) command 111. The storage device manager 101 can automatically send command 114 including metadata 112 to device driver 103. Device driver 103 can receive command 114 including metadata 112 from storage device manager 101.

[0036] Device driver 103 can configure a volume at SCM device 104 based on command 114 and metadata 112. For example, device driver 103 can specify reconfiguration 118 based on command 114 and metadata 112. Device driver 103 can implement reconfiguration 118 at SCM device 104, including one or more of the following: volume creation, volume modification (e.g., resizing, changing location, etc.), volume corruption, allocating a volume to a partition (virtual machine), etc.

[0037] After reconfiguration 118 is implemented, SCM device 104 can operate as expected and according to command 114 and metadata 112 for a certain period of time. The operation of SCM device 104 according to reconfiguration 118 can be substantially similar to (if not different from) the operation of SCM device 104 according to configuration 116. For example, the volume configuration operation associated with command 111 can be automatically reimplemented through command 114.

[0038] In one aspect, storage device 102 is used to store volume metadata for a plurality of other, more volatile (less stable) storage devices, which may include one or more SCM devices. Each of the plurality of storage devices may be associated with a unique (e.g., hardware) device identifier. When a user or program formulates a volume command, the user or program may include the unique device identifier in the volume command, possibly included in the included metadata. When a device driver (e.g., 103) notifies storage device manager 101 of persistent loss at an SCM device (or other storage device), the device driver may include the unique device identifier in the notification.

[0039] Therefore, volume commands and persistence loss notifications received at storage device manager 101 may include a unique device identifier. Storage device manager 101 can utilize the received unique device identifier to distinguish metadata associated with different storage devices. For example, the storage device manager can store and access volume metadata using the received device identifier. Received volume commands and persistence loss notifications may include / indicate the device identifier. Storage device manager 101 can use the device identifier to link received, stored, or accessed volume metadata to a suitable more volatile (less stable) storage device. For example, storage device manager 101 can query storage device 102 using the device identifier to access volume metadata associated with the storage device corresponding to that device identifier.

[0040] Figure 3 A specific configuration of computer hardware platform 300 is shown. The computer hardware platform can be used to implement a computer system including components of computer architecture 100.

[0041] The computer platform 300 may include a central processing unit (CPU) 304, a hard disk drive (HDD) 306, random access memory (RAM) and / or read-only memory (ROM) 308, a keyboard 310, a mouse 312, a display 314, and a communication interface 316, which are connected to the system bus 302.

[0042] HDD 306 may include the ability to store executed programs (such as device manager 101). Storage device manager 101 may include various modules configured to perform different functions, including a volume command processor 342, a metadata storage and query module 346, and a persistence detector 348. The volume command processor 342 may be configured to process volume commands, including extracting volume metadata from received volume commands, forwarding volume commands to device drivers, and forming volume commands from stored metadata for use when reconfiguring volumes that have lost persistence. The metadata storage and query module 346 may be configured to store volume metadata at (e.g., a less volatile) storage device and access volume metadata from that storage device (e.g., via a device identifier). The persistence detector 348 may be configured to monitor persistence at any of a plurality of (e.g., more volatile) storage devices, and the loss of detected persistence at any of the plurality of (e.g., more volatile) storage devices.

[0043] Example operating platform

[0044] Implementations may include or utilize dedicated or general-purpose computers, comprising computer hardware such as, for example, one or more computer and / or hardware processors (including any of a central processing unit (CPU) and / or a graphics processing unit (GPU), a general-purpose GPU (GPGPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a tensor processing unit (TPU)) and system memory, as will be discussed in more detail below. Implementations also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible by a general-purpose or dedicated computer system. A computer-readable medium storing computer-executable instructions is a computer storage medium (device). A computer-readable medium carrying computer-executable instructions is a transmission medium. Thus, by way of example and not limitation, implementations may include at least two distinctly different types of computer-readable media: computer storage media (devices) and transmission media.

[0045] Computer storage media (devices) include SCM (and other intermediate storage solutions), RAM, ROM, EEPROM, CD-ROM, solid-state drives (“SSDs”) (e.g., RAM-based or flash-based), shingled magnetic recording (“SMR”) devices, flash memory, phase-change memory (“PCM”), other types of memory, other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer.

[0046] In one aspect, one or more processors are configured to execute instructions (e.g., computer-readable instructions, computer-executable instructions, etc.) to perform any of the plurality of described operations. One or more processors may access information from system memory and / or store information in system memory. One or more processors may (e.g., automatically) transform information between different formats, such as, for example, transforming information between any of the following: volume commands, volume metadata, queries, volume configuration, volume reconfiguration, persistent loss notification, persistent loss detection, etc.

[0047] System memory may be coupled to one or more processors and may store instructions (e.g., computer-readable instructions, computer-executable instructions, etc.) that are executed by one or more processors. System memory may also be configured to store any of a number of other types of data generated and / or transformed by the described components, such as, for example, volume commands, volume metadata, queries, volume configurations, volume reconfigurations, persistent loss notifications, persistent loss detection, etc.

[0048] A “network” is defined as one or more data links that enable the transfer of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or another communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computer appropriately considers that connection as a transmission medium. A transmission medium may include networks and / or data links, which may be used to carry desired program code in the form of computer-executable instructions or data structures, and which may be accessible by general-purpose or special-purpose computers. Combinations of the above should also be included within the scope of computer-readable media.

[0049] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (device) (or vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in the RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computer system RAM and / or a more non-volatile computer storage medium (device) at the computer system. Therefore, it should be understood that computer storage media (devices) can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0050] Computer-executable instructions comprise, for example, instructions and data that, in response to execution at a processor, cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a specific function or set of functions. Computer-executable instructions can be, for example, binary numbers, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. Rather, the described features and actions are disclosed in exemplary forms for implementing the claims.

[0051] Those skilled in the art will recognize that the described aspects can be practiced in network computing environments with a variety of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, wearable devices, multi-core processor systems, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, mobile phones, PDAs, tablets, routers, switches, and so on. The described aspects can also be practiced in distributed system environments, where both local and remote computer systems perform tasks via network links (via hardwired data links, wireless data links, or a combination of hardwired and wireless data links). In a distributed system environment, program modules can reside on both local and remote memory storage devices.

[0052] Furthermore, where appropriate, the functionality described herein can be performed using one or more of the following: hardware, software, firmware, digital components, or analog components. For example, one or more field-programmable gate arrays (FPGAs) and / or one or more application-specific integrated circuits (ASICs) and / or one or more tensor processing units (TPUs) can be programmed to implement one or more systems and processes described herein. The hardware, software, firmware, digital components, or analog components can be specifically tailored to (re)configure volumes at more volatile storage devices in response to persistent loss. In another example, computer code is configured to execute in one or more processors and may include hardware logic / circuit controlled by the computer code. These exemplary devices are provided herein for illustrative purposes and are not intended to be limiting. Embodiments of this disclosure can be implemented in devices of further types.

[0053] The described aspects can also be implemented in a cloud computing environment. In this specification and the appended claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be adopted in the market to provide ubiquitous and convenient on-demand access to a shared pool of configurable computing resources (e.g., computing resources, networking resources, and storage resources). The shared pool of configurable computing resources can be provisioned via virtualization and released with low effort or service provider interaction, and then scaled accordingly.

[0054] Cloud computing models can include various features such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurement services. Cloud computing models can also exhibit various service models, such as Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). Cloud computing models can also be deployed using different deployment models such as private cloud, community cloud, public cloud, and hybrid cloud. In this specification and the appended claims, a “cloud computing environment” means an environment employing cloud computing.

[0055] in conclusion

[0056] Various embodiments of this teaching have been described for illustrative purposes, but are not intended to be exhaustive or limiting of the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The technical terms used herein are chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0057] While what is considered the optimal state and / or other examples have been described above, it should be understood that various modifications may be made therein, and the subject matter disclosed herein can be implemented in various forms and examples, and the teachings can be applied to many applications, of which only a few have been described herein. The appended claims are intended to protect any and all applications, modifications, and variations that fall within the true scope of this teaching.

[0058] The components, steps, features, purposes, benefits, and advantages discussed herein are merely illustrative. None of them, or the discussion relating to them, is intended to limit the scope of protection. While various advantages have been discussed herein, it will be understood that not all embodiments are necessarily intended to include all advantages. Unless otherwise stated, all measurements, values, grades, locations, sizes, dimensions, and other specifications set forth in this specification (including in the appended claims) are approximate, not precise. They are intended to have a reasonable scope consistent with the functions they pertain to and the conventions of the art to which they belong.

[0059] Many other embodiments have also been considered. These embodiments include those with fewer, additional, and / or different components, steps, features, purposes, benefits, and advantages. These also include embodiments in which the components and / or steps are arranged and / or ordered in different ways.

[0060] This document describes aspects of the present disclosure with reference to calling flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each step of the flowcharts and / or block diagrams, and combinations of boxes in the calling flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0061] These computer-readable program instructions may be provided to a processor of a computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a manner for implementing the functions / actions specified in one or more blocks of a call flow procedure and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored contains an article of manufacture comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a call flow procedure and / or block diagram.

[0062] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more blocks of a call flow procedure and / or block diagram.

[0063] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a calling flowchart or block diagram may represent a module, fragment, or portion of instructions containing one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two blocks shown consecutively may actually be implemented substantially simultaneously, or these blocks may sometimes be implemented in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or calling flowcharts, and combinations of blocks in the block diagrams and / or calling flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or carries out a combination of dedicated hardware and computer instructions.

[0064] Although the foregoing has been described in conjunction with exemplary embodiments, it should be understood that the term "exemplary" means only as an example, and not the best or optimal. Apart from what has just been stated above, whether or not it is recited in the claims, what has been stated or shown is not intended or should not be construed as resulting in the offering to the public of any component, step, feature, purpose, benefit, advantage, or equivalent.

[0065] It will be understood that, unless otherwise specified herein, the terms and expressions used herein have the general meaning consistent with those in the respective fields of investigation and research to which they correspond. Relational terms such as "first" and "second" may be used only to distinguish one entity or action from another, without necessarily requiring or implying any actual such relationship or order between these entities or actions. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such a process, method, article, or apparatus. Without further constraints, an element preceded by "a" or "an" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes that element.

[0066] This summary of disclosure is provided to allow the reader to quickly determine the nature of this technical disclosure. It should be understood that it is not intended to be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the detailed description above, various features have been grouped together in various embodiments for the purpose of fluent expression of this disclosure. This method of disclosure should not be construed as reflecting an intention that the claimed embodiments have more features than those expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are thus incorporated into the detailed description, wherein each claim is, on its own, a separately claimed subject matter.

Claims

1. A computing device, comprising: processor; Storage-level memory (SCM) storage device coupled to the processor; Another storage device that is less prone to loss than the SCM storage device coupled to the processor; The SCM device driver that manages the volume of the SCM storage device; A storage device manager stored in the other storage device, wherein the processor executes the storage device manager to configure the computing device to perform actions including the following: Receive a volume command including volume metadata associated with the storage volume of the SCM storage device; The volume metadata is stored on the other storage device; Configure the storage volume according to the volume command, including forwarding the volume command to the SCM device driver; After forwarding the volume command, receive a notification of persistent loss at the SCM storage device; Upon receiving the notification of the persistent data loss, the volume metadata is retrieved from the other storage device; and The storage volume is automatically reconfigured according to the volume command, including submitting the obtained volume metadata to the SCM device driver.

2. The computing device of claim 1, wherein configuring the storage volume according to the volume command includes allocating the storage volume to a partition or a virtual machine.

3. The computing device of claim 1, wherein configuring the storage volume according to the volume command includes creating the storage volume.

4. The computing device of claim 1, wherein receiving a volume command including the volume metadata includes receiving one or more of the following: volume identifier, volume name, volume size, volume location, or volume owner.

5. The computing device of claim 1, wherein storing the volume metadata at the other storage device comprises storing the volume metadata at a non-volatile random access memory (NvRAM) device.

6. The computing device of claim 1, wherein automatically reconfiguring the storage volume according to the volume command includes automatically assigning the storage volume to a partition or virtual machine.

7. The computing device of claim 1, wherein automatically reconfiguring the storage volume according to the volume command includes automatically creating the storage volume.

8. The computing device of claim 1, wherein receiving a volume command comprises one of: receiving the volume command from a user interface or receiving the volume command from a loader.

9. A non-transitory computer-readable storage medium tangibly embodying computer-readable program code having computer-readable instructions, said computer-readable instructions, when executed, causing a user equipment to perform a method for configuring a storage device, said method comprising: Receive volume commands that include volume metadata associated with the storage volume of the storage class memory (SCM) storage device; The volume metadata is stored on another storage device that is less prone to loss than the SCM storage device. Configure the storage volume according to the volume command, including forwarding the volume command to the SCM device driver; After forwarding the volume command, receive a notification of persistent loss at the SCM storage device; Upon receiving the notification of the loss of persistence, the volume metadata is retrieved from the other storage device; as well as The storage volume is automatically reconfigured according to the volume command, including submitting the obtained volume metadata to the SCM device driver.

10. The non-transitory computer-readable storage medium of claim 9, wherein configuring the storage volume according to the volume command includes allocating the volume to a partition or a virtual machine.

11. The non-transitory computer-readable storage medium of claim 9, wherein configuring the storage volume according to the volume command includes creating the storage volume.

12. The non-transitory computer-readable storage medium of claim 9, wherein obtaining the volume metadata from the other storage device includes obtaining one or more of the following: volume identifier, volume name, volume size, volume location, or volume owner.

13. The non-transitory computer-readable storage medium of claim 9, wherein automatically reconfiguring the storage volume according to the volume command includes automatically assigning the storage volume to a partition or virtual machine.

14. The non-transitory computer-readable storage medium of claim 9, wherein automatically reconfiguring the storage volume according to the volume command includes automatically creating the storage volume.

15. A computer-implemented method for configuring a storage device, the method comprising: Receive volume commands that include volume metadata associated with the storage volume of the storage class memory (SCM) storage device; The volume metadata is stored on another storage device that is less prone to loss than the SCM storage device. Configure the storage volume according to the volume command, including forwarding the volume command to the SCM device driver; After forwarding the volume command, receive a notification of persistent loss at the SCM storage device; Upon receiving the notification of the loss of persistence, the volume metadata is retrieved from the other storage device; as well as The storage volume is automatically reconfigured according to the volume command, including submitting the obtained volume metadata to the SCM device driver.

16. The computer-implemented method of claim 15, wherein configuring the storage volume according to the volume command includes assigning the storage volume to a partition or a virtual machine.

17. The computer-implemented method of claim 16, wherein automatically reconfiguring the storage volume according to the volume command includes automatically reassigning the storage volume to the partition or virtual machine.

18. The computer-implemented method of claim 15, wherein configuring the storage volume according to the volume command includes creating the storage volume.

19. The computer-implemented method of claim 18, wherein automatically reconfiguring the storage volume according to the volume command includes automatically recreating the storage volume.

20. The computer-implemented method according to claim 15, The volume command that receives volume metadata includes receiving one or more of the following: volume identifier, volume name, volume size, volume location, or volume owner; and Obtaining the volume metadata from the other storage device includes obtaining one or more of the following: volume identifier, volume name, volume size, volume location, or volume owner.