System and method for moving metadata without updating references used by the metadata

A method, computer program product, and computer system for virtualizing, by a computing device, a physical metadata space into a virtual metadata space. A translation table from the virtual metadata space to the physical metadata space may be implemented. Metadata in the physical metadata space may be cached based upon the virtual metadata space. The metadata in the physical metadata space may be moved without updating references associated with the metadata in the physical metadata space.

BACKGROUND

Storage systems have components whose responsibility is to map a user-visible logical address space to an internal physical address space, and implement various features such as snapshots, data compression, data deduplication, etc. Such mapping and features may rely on different types of metadata to be implemented. This metadata (e.g., Tops, Mids, Leafs, Virtual Logical Blocks (VLBs) pointing to Physical Large Blocks (PLBs), etc.) are typically stored persistently as, e.g., 4k blocks on drives and different metadata blocks reference each other by their block-addresses.

BRIEF SUMMARY OF DISCLOSURE

In one example implementation, a method, performed by one or more computing devices, may include but is not limited to virtualizing, by a computing device, a physical metadata space into a virtual metadata space. A translation table from the virtual metadata space to the physical metadata space may be implemented. Metadata in the physical metadata space may be cached based upon the virtual metadata space. The metadata in the physical metadata space may be moved without updating references associated with the metadata in the physical metadata space.

One or more of the following example features may be included. The translation table may be implemented on a boot-tier at a static address. Modifications to the translation table may be tracked in a metadata log for destaging to the boot-tier. The physical metadata space may be implemented as a log-structured store. The physical metadata space may be implemented on a parity RAID configuration. Destaging of the metadata from the metadata log may be written to a new segment. The translation table may be updated to track mapping of the new segment.

In another example implementation, a computing system may include one or more processors and one or more memories configured to perform operations that may include but are not limited to virtualizing, by a computing device, a physical metadata space into a virtual metadata space. A translation table from the virtual metadata space to the physical metadata space may be implemented. Metadata in the physical metadata space may be cached based upon the virtual metadata space. The metadata in the physical metadata space may be moved without updating references associated with the metadata in the physical metadata space.

One or more of the following example features may be included. The translation table may be implemented on a boot-tier at a static address. Modifications to the translation table may be tracked in a metadata log for destaging to the boot-tier. The physical metadata space may be implemented as a log-structured store. The physical metadata space may be implemented on a parity RAID configuration. Destaging of the metadata from the metadata log may be written to a new segment. The translation table may be updated to track mapping of the new segment.

In another example implementation, a computer program product may reside on a computer readable storage medium having a plurality of instructions stored thereon which, when executed across one or more processors, may cause at least a portion of the one or more processors to perform operations that may include but are not limited to virtualizing, by a computing device, a physical metadata space into a virtual metadata space. A translation table from the virtual metadata space to the physical metadata space may be implemented. Metadata in the physical metadata space may be cached based upon the virtual metadata space. The metadata in the physical metadata space may be moved without updating references associated with the metadata in the physical metadata space.

One or more of the following example features may be included. The translation table may be implemented on a boot-tier at a static address. Modifications to the translation table may be tracked in a metadata log for destaging to the boot-tier. The physical metadata space may be implemented as a log-structured store. The physical metadata space may be implemented on a parity RAID configuration. Destaging of the metadata from the metadata log may be written to a new segment. The translation table may be updated to track mapping of the new segment.

DETAILED DESCRIPTION

In some implementations, the present disclosure may be embodied as a method, system, or computer program product. Accordingly, in some implementations, the present disclosure may take the form of an entirely hardware implementation, an entirely software implementation (including firmware, resident software, micro-code, etc.) or an implementation combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, in some implementations, the present disclosure may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.

In some implementations, any suitable computer usable or computer readable medium (or media) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer-usable, or computer-readable, storage medium (including a storage device associated with a computing device or client electronic device) may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable medium may include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a digital versatile disk (DVD), a static random access memory (SRAM), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, a media such as those supporting the internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be a suitable medium upon which the program is stored, scanned, compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of the present disclosure, a computer-usable or computer-readable, storage medium may be any tangible medium that can contain or store a program for use by or in connection with the instruction execution system, apparatus, or device.

In some implementations, computer program code for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Java®, Smalltalk, C++ or the like. Java® and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. However, the computer program code for carrying out operations of the present disclosure may also be written in conventional procedural programming languages, such as the “C” programming language, PASCAL, or similar programming languages, as well as in scripting languages such as Javascript, PERL, or Python. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the internet using an Internet Service Provider). In some implementations, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs) or other hardware accelerators, micro-controller units (MCUs), or programmable logic arrays (PLAs) may execute the computer readable program instructions/code by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

In some implementations, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus (systems), methods and computer program products according to various implementations of the present disclosure. Each block in the flowchart and/or block diagrams, and combinations of blocks in the flowchart and/or block diagrams, may represent a module, segment, or portion of code, which comprises one or more executable computer program instructions for implementing the specified logical function(s)/act(s). These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program instructions, which may execute via the processor of the computer or other programmable data processing apparatus, create the ability to implement one or more of the functions/acts specified in the flowchart and/or block diagram block or blocks or combinations thereof. It should be noted that, in some implementations, the functions noted in the block(s) may occur out of the order noted in the figures (or combined or omitted). For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

In some implementations, the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed (not necessarily in a particular order) on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts (not necessarily in a particular order) specified in the flowchart and/or block diagram block or blocks or combinations thereof.

Referring now to the example implementation ofFIG. 1, there is shown map process10that may reside on and may be executed by a computer (e.g., computer12), which may be connected to a network (e.g., network14) (e.g., the internet or a local area network). Examples of computer12(and/or one or more of the client electronic devices noted below) may include, but are not limited to, a storage system (e.g., a Network Attached Storage (NAS) system, a Storage Area Network (SAN)), a personal computer(s), a laptop computer(s), mobile computing device(s), a server computer, a series of server computers, a mainframe computer(s), or a computing cloud(s). As is known in the art, a SAN may include one or more of the client electronic devices, including a Redundant Array of Inexpensive Disks/Redundant Array of Independent Disks (RAID) device and a NAS system. In some implementations, each of the aforementioned may be generally described as a computing device. In certain implementations, a computing device may be a physical or virtual device. In many implementations, a computing device may be any device capable of performing operations, such as a dedicated processor, a portion of a processor, a virtual processor, a portion of a virtual processor, portion of a virtual device, or a virtual device. In some implementations, a processor may be a physical processor or a virtual processor. In some implementations, a virtual processor may correspond to one or more parts of one or more physical processors. In some implementations, the instructions/logic may be distributed and executed across one or more processors, virtual or physical, to execute the instructions/logic. Computer12may execute an operating system, for example, but not limited to, Microsoft® Windows®; Mac® OS X®; Red Hat® Linux®, Windows® Mobile, Chrome OS, Blackberry OS, Fire OS, or a custom operating system. (Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other countries or both; Mac and OS X are registered trademarks of Apple Inc. in the United States, other countries or both; Red Hat is a registered trademark of Red Hat Corporation in the United States, other countries or both; and Linux is a registered trademark of Linus Torvalds in the United States, other countries or both).

In some implementations, as will be discussed below in greater detail, a map process, such as map process10ofFIG. 1, may virtualize, by a computing device, a physical metadata space into a virtual metadata space. A translation table from the virtual metadata space to the physical metadata space may be implemented. Metadata in the physical metadata space may be cached based upon the virtual metadata space. The metadata in the physical metadata space may be moved without updating references associated with the metadata in the physical metadata space.

In some implementations, the instruction sets and subroutines of map process10, which may be stored on storage device, such as storage device16, coupled to computer12, may be executed by one or more processors and one or more memory architectures included within computer12. In some implementations, storage device16may include but is not limited to: a hard disk drive; all forms of flash memory storage devices; a tape drive; an optical drive; a RAID array (or other array); a random access memory (RAM); a read-only memory (ROM); or combination thereof. In some implementations, storage device16may be organized as an extent, an extent pool, a RAID extent (e.g., an example 4D+1P R5, where the RAID extent may include, e.g., five storage device extents that may be allocated from, e.g., five different storage devices), a mapped RAID (e.g., a collection of RAID extents), or combination thereof.

In some implementations, network14may be connected to one or more secondary networks (e.g., network18), examples of which may include but are not limited to: a local area network; a wide area network or other telecommunications network facility; or an intranet, for example. The phrase “telecommunications network facility,” as used herein, may refer to a facility configured to transmit, and/or receive transmissions to/from one or more mobile client electronic devices (e.g., cellphones, etc.) as well as many others.

In some implementations, computer12may include a data store, such as a database (e.g., relational database, object-oriented database, triplestore database, etc.) and may be located within any suitable memory location, such as storage device16coupled to computer12. In some implementations, data, metadata, information, etc. described throughout the present disclosure may be stored in the data store. In some implementations, computer12may utilize any known database management system such as, but not limited to, DB2, in order to provide multi-user access to one or more databases, such as the above noted relational database. In some implementations, the data store may also be a custom database, such as, for example, a flat file database or an XML database. In some implementations, any other form(s) of a data storage structure and/or organization may also be used. In some implementations, map process10may be a component of the data store, a standalone application that interfaces with the above noted data store and/or an applet/application that is accessed via client applications22,24,26,28. In some implementations, the above noted data store may be, in whole or in part, distributed in a cloud computing topology. In this way, computer12and storage device16may refer to multiple devices, which may also be distributed throughout the network.

In some implementations, computer12may execute a storage management application (e.g., storage management application21), examples of which may include, but are not limited to, e.g., a storage system application, a cloud computing application, a data synchronization application, a data migration application, a garbage collection application, or other application that allows for the implementation and/or management of data in a clustered (or non-clustered) environment (or the like). In some implementations, map process10and/or storage management application21may be accessed via one or more of client applications22,24,26,28. In some implementations, map process10may be a standalone application, or may be an applet/application/script/extension that may interact with and/or be executed within storage management application21, a component of storage management application21, and/or one or more of client applications22,24,26,28. In some implementations, storage management application21may be a standalone application, or may be an applet/application/script/extension that may interact with and/or be executed within map process10, a component of map process10, and/or one or more of client applications22,24,26,28. In some implementations, one or more of client applications22,24,26,28may be a standalone application, or may be an applet/application/script/extension that may interact with and/or be executed within and/or be a component of map process10and/or storage management application21. Examples of client applications22,24,26,28may include, but are not limited to, e.g., a storage system application, a cloud computing application, a data synchronization application, a data migration application, a garbage collection application, or other application that allows for the implementation and/or management of data in a clustered (or non-clustered) environment (or the like), a standard and/or mobile web browser, an email application (e.g., an email client application), a textual and/or a graphical user interface, a customized web browser, a plugin, an Application Programming Interface (API), or a custom application. The instruction sets and subroutines of client applications22,24,26,28, which may be stored on storage devices30,32,34,36, coupled to client electronic devices38,40,42,44, may be executed by one or more processors and one or more memory architectures incorporated into client electronic devices38,40,42,44.

In some implementations, one or more of storage devices30,32,34,36, may include but are not limited to: hard disk drives; flash drives, tape drives; optical drives; RAID arrays; random access memories (RAM); and read-only memories (ROM). Examples of client electronic devices38,40,42,44(and/or computer12) may include, but are not limited to, a personal computer (e.g., client electronic device38), a laptop computer (e.g., client electronic device40), a smart/data-enabled, cellular phone (e.g., client electronic device42), a notebook computer (e.g., client electronic device44), a tablet, a server, a television, a smart television, a smart speaker, an Internet of Things (IoT) device, a media (e.g., video, photo, etc.) capturing device, and a dedicated network device. Client electronic devices38,40,42,44may each execute an operating system, examples of which may include but are not limited to, Android™, Apple® iOS®, Mac® OS X®; Red Hat® Linux®, Windows® Mobile, Chrome OS, Blackberry OS, Fire OS, or a custom operating system.

In some implementations, one or more of client applications22,24,26,28may be configured to effectuate some or all of the functionality of map process10(and vice versa). Accordingly, in some implementations, map process10may be a purely server-side application, a purely client-side application, or a hybrid server-side/client-side application that is cooperatively executed by one or more of client applications22,24,26,28and/or map process10.

In some implementations, one or more of client applications22,24,26,28may be configured to effectuate some or all of the functionality of storage management application21(and vice versa). Accordingly, in some implementations, storage management application21may be a purely server-side application, a purely client-side application, or a hybrid server-side/client-side application that is cooperatively executed by one or more of client applications22,24,26,28and/or storage management application21. As one or more of client applications22,24,26,28, map process10, and storage management application21, taken singly or in any combination, may effectuate some or all of the same functionality, any description of effectuating such functionality via one or more of client applications22,24,26,28, map process10, storage management application21, or combination thereof, and any described interaction(s) between one or more of client applications22,24,26,28, map process10, storage management application21, or combination thereof to effectuate such functionality, should be taken as an example only and not to limit the scope of the disclosure.

In some implementations, one or more of users46,48,50,52may access computer12and map process10(e.g., using one or more of client electronic devices38,40,42,44) directly through network14or through secondary network18. Further, computer12may be connected to network14through secondary network18, as illustrated with phantom link line54. Map process10may include one or more user interfaces, such as browsers and textual or graphical user interfaces, through which users46,48,50,52may access map process10.

In some implementations, the various client electronic devices may be directly or indirectly coupled to network14(or network18). For example, client electronic device38is shown directly coupled to network14via a hardwired network connection. Further, client electronic device44is shown directly coupled to network18via a hardwired network connection. Client electronic device40is shown wirelessly coupled to network14via wireless communication channel56established between client electronic device40and wireless access point (i.e., WAP)58, which is shown directly coupled to network14. WAP 58 may be, for example, an IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, Wi-Fi®, RFID, and/or Bluetooth™ (including Bluetooth™ Low Energy) device that is capable of establishing wireless communication channel56between client electronic device40and WAP 58. Client electronic device42is shown wirelessly coupled to network14via wireless communication channel60established between client electronic device42and cellular network/bridge62, which is shown by example directly coupled to network14.

In some implementations, some or all of the IEEE 802.11x specifications may use Ethernet protocol and carrier sense multiple access with collision avoidance (i.e., CSMA/CA) for path sharing. The various 802.11x specifications may use phase-shift keying (i.e., PSK) modulation or complementary code keying (i.e., CCK) modulation, for example. Bluetooth™ (including Bluetooth™ Low Energy) is a telecommunications industry specification that allows, e.g., mobile phones, computers, smart phones, and other electronic devices to be interconnected using a short-range wireless connection. Other forms of interconnection (e.g., Near Field Communication (NFC)) may also be used.

In some implementations, various I/O requests (e.g., I/O request15) may be sent from, e.g., client applications22,24,26,28to, e.g., computer12. Examples of I/O request15may include but are not limited to, data write requests (e.g., a request that content be written to computer12) and data read requests (e.g., a request that content be read from computer12).

Data Storage System:

Referring also to the example implementation ofFIGS. 2-3(e.g., where computer12may be configured as a data storage system), computer12may include storage processor100and a plurality of storage targets (e.g., storage targets102,104,106,108,110). In some implementations, storage targets102,104,106,108,110may include any of the above-noted storage devices. In some implementations, storage targets102,104,106,108,110may be configured to provide various levels of performance and/or high availability. For example, storage targets102,104,106,108,110may be configured to form a non-fully-duplicative fault-tolerant data storage system (such as a non-fully-duplicative RAID data storage system), examples of which may include but are not limited to: RAID 3 arrays, RAID 4 arrays, RAID 5 arrays, and/or RAID 6 arrays. It will be appreciated that various other types of RAID arrays may be used without departing from the scope of the present disclosure.

While in this particular example, computer12is shown to include five storage targets (e.g., storage targets102,104,106,108,110), this is for example purposes only and is not intended limit the present disclosure. For instance, the actual number of storage targets may be increased or decreased depending upon, e.g., the level of redundancy/performance/capacity required.

Further, the storage targets (e.g., storage targets102,104,106,108,110) included with computer12may be configured to form a plurality of discrete storage arrays. For instance, and assuming for example purposes only that computer12includes, e.g., ten discrete storage targets, a first five targets (of the ten storage targets) may be configured to form a first RAID array and a second five targets (of the ten storage targets) may be configured to form a second RAID array.

In some implementations, one or more of storage targets102,104,106,108,110may be configured to store coded data (e.g., via storage management process21), wherein such coded data may allow for the regeneration of data lost/corrupted on one or more of storage targets102,104,106,108,110. Examples of such coded data may include but is not limited to parity data and Reed-Solomon data. Such coded data may be distributed across all of storage targets102,104,106,108,110or may be stored within a specific storage target.

Examples of storage targets102,104,106,108,110may include one or more data arrays, wherein a combination of storage targets102,104,106,108,110(and any processing/control systems associated with storage management application21) may form data array112.

The manner in which computer12is implemented may vary depending upon e.g., the level of redundancy/performance/capacity required. For example, computer12may be configured as a SAN (i.e., a Storage Area Network), in which storage processor100may be, e.g., a dedicated computing system and each of storage targets102,104,106,108,110may be a RAID device. An example of storage processor100may include but is not limited to a VPLEX™, VNX™, TRIDENT™, or Unity™ system offered by Dell EMC™ of Hopkinton, Mass.

In the example where computer12is configured as a SAN, the various components of computer12(e.g., storage processor100, and storage targets102,104,106,108,110) may be coupled using network infrastructure114, examples of which may include but are not limited to an Ethernet (e.g., Layer2or Layer3) network, a fiber channel network, an InfiniB and network, or any other circuit switched/packet switched network.

As discussed above, various I/O requests (e.g., I/O request15) may be generated. For example, these I/O requests may be sent from, e.g., client applications22,24,26,28to, e.g., computer12. Additionally/alternatively (e.g., when storage processor100is configured as an application server or otherwise), these I/O requests may be internally generated within storage processor100(e.g., via storage management process21). Examples of I/O request15may include but are not limited to data write request116(e.g., a request that content118be written to computer12) and data read request120(e.g., a request that content118be read from computer12).

In some implementations, during operation of storage processor100, content118to be written to computer12may be received and/or processed by storage processor100(e.g., via storage management process21). Additionally/alternatively (e.g., when storage processor100is configured as an application server or otherwise), content118to be written to computer12may be internally generated by storage processor100(e.g., via storage management process21).

As discussed above, the instruction sets and subroutines of storage management application21, which may be stored on storage device16included within computer12, may be executed by one or more processors and one or more memory architectures included with computer12. Accordingly, in addition to being executed on storage processor100, some or all of the instruction sets and subroutines of storage management application21(and/or map process10) may be executed by one or more processors and one or more memory architectures included with data array112.

In some implementations, storage processor100may include front end cache memory system122. Examples of front end cache memory system122may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system), a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system), and/or any of the above-noted storage devices.

In some implementations, storage processor100may initially store content118within front end cache memory system122. Depending upon the manner in which front end cache memory system122is configured, storage processor100(e.g., via storage management process21) may immediately write content118to data array112(e.g., if front end cache memory system122is configured as a write-through cache) or may subsequently write content118to data array112(e.g., if front end cache memory system122is configured as a write-back cache).

In some implementations, one or more of storage targets102,104,106,108,110may include a backend cache memory system. Examples of the backend cache memory system may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system), a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system), and/or any of the above-noted storage devices.

As discussed above, one or more of storage targets102,104,106,108,110may be a RAID device. For instance, and referring also toFIG. 3, there is shown example target150, wherein target150may be one example implementation of a RAID implementation of, e.g., storage target102, storage target104, storage target106, storage target108, and/or storage target110. An example of target150may include but is not limited to a VPLEX™, VNX™, TRIDENT™, or Unity™ system offered by Dell EMC™ of Hopkinton, Mass. Examples of storage devices154,156,158,160,162may include one or more electro-mechanical hard disk drives, one or more solid-state/flash devices, and/or any of the above-noted storage devices. It will be appreciated that while the term “disk” or “drive” may be used throughout, these may refer to and be used interchangeably with any types of appropriate storage devices as the context and functionality of the storage device permits.

In some implementations, target150may include storage processor152and a plurality of storage devices (e.g., storage devices154,156,158,160,162). Storage devices154,156,158,160,162may be configured to provide various levels of performance and/or high availability (e.g., via storage management process21). For example, one or more of storage devices154,156,158,160,162(or any of the above-noted storage devices) may be configured as a RAID 0 array, in which data is striped across storage devices. By striping data across a plurality of storage devices, improved performance may be realized. However, RAID 0 arrays may not provide a level of high availability. Accordingly, one or more of storage devices154,156,158,160,162(or any of the above-noted storage devices) may be configured as a RAID 1 array, in which data is mirrored between storage devices. By mirroring data between storage devices, a level of high availability may be achieved as multiple copies of the data may be stored within storage devices154,156,158,160,162.

While storage devices154,156,158,160,162are discussed above as being configured in a RAID 0 or RAID 1 array, this is for example purposes only and not intended to limit the present disclosure, as other configurations are possible. For example, storage devices154,156,158,160,162may be configured as a RAID 3, RAID 4, RAID 5 or RAID 6 array.

While in this particular example, target150is shown to include five storage devices (e.g., storage devices154,156,158,160,162), this is for example purposes only and not intended to limit the present disclosure. For instance, the actual number of storage devices may be increased or decreased depending upon, e.g., the level of redundancy/performance/capacity required.

In some implementations, one or more of storage devices154,156,158,160,162may be configured to store (e.g., via storage management process21) coded data, wherein such coded data may allow for the regeneration of data lost/corrupted on one or more of storage devices154,156,158,160,162. Examples of such coded data may include but are not limited to parity data and Reed-Solomon data. Such coded data may be distributed across all of storage devices154,156,158,160,162or may be stored within a specific storage device.

The manner in which target150is implemented may vary depending upon e.g., the level of redundancy/performance/capacity required. For example, target150may be a RAID device in which storage processor152is a RAID controller card and storage devices154,156,158,160,162are individual “hot-swappable” hard disk drives. Another example of target150may be a RAID system, examples of which may include but are not limited to an NAS (i.e., Network Attached Storage) device or a SAN (i.e., Storage Area Network).

In some implementations, storage target150may execute all or a portion of storage management application21. The instruction sets and subroutines of storage management application21, which may be stored on a storage device (e.g., storage device164) coupled to storage processor152, may be executed by one or more processors and one or more memory architectures included with storage processor152. Storage device164may include but is not limited to any of the above-noted storage devices.

As discussed above, computer12may be configured as a SAN, wherein storage processor100may be a dedicated computing system and each of storage targets102,104,106,108,110may be a RAID device. Accordingly, when storage processor100processes data requests116,120, storage processor100(e.g., via storage management process21) may provide the appropriate requests/content (e.g., write request166, content168and read request170) to, e.g., storage target150(which is representative of storage targets102,104,106,108and/or110).

In some implementations, during operation of storage processor152, content168to be written to target150may be processed by storage processor152(e.g., via storage management process21). Storage processor152may include cache memory system172. Examples of cache memory system172may include but are not limited to a volatile, solid-state, cache memory system (e.g., a dynamic RAM cache memory system) and/or a non-volatile, solid-state, cache memory system (e.g., a flash-based, cache memory system). During operation of storage processor152, content168to be written to target150may be received by storage processor152(e.g., via storage management process21) and initially stored (e.g., via storage management process21) within front end cache memory system172.

Some storage systems may have a hierarchical log structured implementations. For instance, and referring at least to the exampleFIG. 4, an example logical diagrammatic view of a log structured storage system400is shown. In the example storage system, to support features such as thin-provisioning, snapshots and deduplication/compression, logical address space out of which volumes are created may be mapped to log-structured address space using a tree like data-structure. For example, n-way (e.g., where n=512) tree with a depth of 4 (Root-node, Top-node, Mid-node, Leaf-node) may describe 2 MB of log-space at 4k block size. The 4-level indirection scheme to access user data may be as follows:

Root: This may be the root of the log structured hierarchy that may eventually point to multiple volumes.

Leaf: Logical Block Address (LBA) representation layer, generally organized as a tree. Each leaf entry generally corresponds to a specific LBA range.

Virtual Logical Block (VLB): Isolates LBA layer from physical storage. Encapsulates physical location of the user data and allows data relocation without necessity to update Leafs.

Physical Large Block (PLB): In log structured systems, the data is stored in contiguous chunks of data, called PLB (e.g., 2 MB chunks). The actual user data pages reside inside, and they may be referenced by one or more VLBs.

As such, the structure may be generally described as: Root→Top→Mid/Leaf (LBA representation)→Virtual Block (VLB)→Physical Block (PLB). For example, after a write operation: Leaf, corresponding to LBA will point to VLB that contains references to PLBs where the user data is stored.

Storage systems have components whose responsibility is to map the user-visible logical address space to the internal physical address space, and implement various features such as snapshots, data compression, data deduplication, etc, as noted above. Such mapping and features may rely on different types of metadata to be implemented. This metadata (e.g., the above-noted Tops, Mids, Leafs, Virtual Logical Blocks (VLBs) pointing to Physical Large Blocks (PLBs), etc.) are typically stored persistently as, e.g., 4k blocks on drives and different metadata blocks reference each other by their block-addresses.

In this model, there is generally no flexibility to move a metadata block around, as all the metadata blocks referencing the to-be-moved metadata block would have to be found and their references would need to be updated, thereby creating a domino effect. As a result, metadata is typically implemented as an in-place over-write system (fixed physical addresses, which has excessive RAID over-head and does not allow for reclaiming of capacity from freed metadata blocks). For performance reasons, metadata may have to be stored in a mirrored configuration, as small-write performance cost in a parity configuration may be excessive. However, this results in a bad trade-off as RAID overhead of a mirrored configuration is 100% in 2-way mirror (200% in 3-way mirror, etc.). Additionally, because of metadata referencing each other by physical addresses, defragmentation and reclaiming of capacity allocated to metadata may become an intractable problem. As such, as will be discussed in greater detail below, to address the above-noted example and non-limiting issues, the present disclosure may provide an architecture to implement metadata as a log-structured system.

The Map Process:

As discussed above and referring also at least to the example implementations ofFIGS. 5-6, map process10may virtualize500, by a computing device, a physical metadata space into a virtual metadata space. Map process10may implement502a translation table from the virtual metadata space to the physical metadata space. Map process10may cache504metadata in the physical metadata space based upon the virtual metadata space. Map process10may move506the metadata in the physical metadata space without updating references associated with the metadata in the physical metadata space.

Referring at least to the example implementation ofFIG. 6, an example diagrammatic view of a Mapper Metadata Architecture600is shown. In the example, there is shown a Mapper metadata602, TxCache604, metadata log (MDL)606, virtual metadata space608, physical metadata space610, and boot-tier612, which will be explained in more detail below.

As will also be discussed below, the present disclosure may introduce a new address space (i.e., a new Virtual Address Space out of virtual metadata space (VMS)608). Mapper metadata (e.g., Tops, Mids, Leafs, VLBs, PLBDesc, PageBin, etc.) may be allocated by map process10as, e.g., 4k blocks out of VMS608, and the Mapper metadata may reference each other based on the virtual block address, which remains fixed. Map process10(e.g., via MDL606) may track changes on VMS blocks and may destage the VMS blocks.

In some implementations, map process10may virtualize500, by a computing device, a physical metadata space into a virtual metadata space, where in some implementations, map process10may implement502a translation table from the virtual metadata space to the physical metadata space. For example, the role of VMS608may be to virtualize500the physical metadata space (PMS) and implements502the translation table from VMS to PMS. For example, in some implementations, the translation table may be implemented on a boot-tier at a static address. For instance, the VMS translation table may be implemented on boot-tier612at a well-known static address (similar to Root-IDPs). Each entry in the VMS translation table may map, e.g., 4k VMS blocks to 4k PMS blocks, which may be similar to virtual address space and VLBs for the user-data tier. The VMS translation table may be implemented as in-place over-write store and may be accessed through TxCache604similar to other Mapper metadata blocks.

In some implementations, modifications to the translation table may be tracked in a metadata log for destaging to the boot-tier. For example, the VMS translation table modifications may be tracked by map process10in606MDL, and destaged by map process10to boot-tier612similar to other Mapper boot-tier blocks. In some implementations, the total size of the VMS translation table may be modeled to be similar in size of the total number of Mid IDPs and provide good amortization with MDL606.

In some implementations, map process10may cache504metadata in the physical metadata space based upon the virtual metadata space. For example, TxCache604(e.g., via map process10) may cache504the metadata in PMS610based on VMS608. As a result, for a metadata cache read-hit (typical case), there is little to no cost of translation from VMS608to PMS610. For example, Mapper (e.g., via map process10) may access its metadata (e.g., Tops, Mids, Leafs, VLBs, etc.) using the VMS address. TxCache604(e.g., via map process10) may also use the VMS address to cache Mapper metadata. When Mapper asks TxCache604for some metadata (using its VMS address) and it is a cache-miss, then it tries to load that metadata block. To load, map process10may first refer to “Translation table on Boot-tier” to translate the VMS address to the PMS address. Once map process10has the PMS address, a read request may be issued to read the block. Once the block is read, it is added to TxCache604using the VMS address. In some implementations, “Translation table on Boot-tier” may also be cached in TxCache604using Boot-tier LBAs, which is different from VMS and PMS.

In some implementations, map process10may move506the metadata in the physical metadata space without updating references associated with the metadata in the physical metadata space. For example, map process10(e.g., via VMS608) may allow for metadata in PMS610to move506around without Mapper metadata602having to update their references (as they are referencing based on VMS block addresses).

In some implementations, the physical metadata space may be implemented as a log-structured store. For example, PMS610may be implemented as a Log-structured store similar to the user-data tier shown inFIG. 4. In some implementations, the physical metadata space may be implemented on a parity RAID configuration. For example, PMS610may be implemented on a parity RAID configuration, which may advantageously minimize RAID over-head.

In some implementations, destaging of the metadata from the metadata log may be written to a new segment and the translation table may be updated to track mapping of the new segment. For example, metadata destages from MDL606may be log-written by map process10to new segments (e.g., PLBs) and the VMS translation table may be updated by map process10to track the new mapping.

Advantageously, (1) PMS610may support compact&append to ingest into partially full PLBs, (2) PMS610may support garbage-collection to consolidate active blocks and create empty PLBs, (3) the PMS garbage-collection may also allow for reclaiming excessive capacity allocated for PMS610and use it for the user-data tier, and (4) VMS608and PMS610architecture may allow for Mapper's metadata602to be stored as compressed blocks.