+

US7127465B2 - Memory-efficient metadata organization in a storage array - Google Patents

Memory-efficient metadata organization in a storage array Download PDF

Info

Publication number
US7127465B2
US7127465B2 US10/261,545 US26154502A US7127465B2 US 7127465 B2 US7127465 B2 US 7127465B2 US 26154502 A US26154502 A US 26154502A US 7127465 B2 US7127465 B2 US 7127465B2
Authority
US
United States
Prior art keywords
slab
metadata
data
tree structure
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime, expires
Application number
US10/261,545
Other versions
US20040064463A1 (en
Inventor
Raghavendra J Rao
Whay Sing Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle America Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Priority to US10/261,545 priority Critical patent/US7127465B2/en
Assigned to SUN MICROSYSTEMS, INC. reassignment SUN MICROSYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LEE, WHAY SING, RAO, RAGHAVENDRA
Publication of US20040064463A1 publication Critical patent/US20040064463A1/en
Application granted granted Critical
Publication of US7127465B2 publication Critical patent/US7127465B2/en
Assigned to Oracle America, Inc. reassignment Oracle America, Inc. MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: Oracle America, Inc., ORACLE USA, INC., SUN MICROSYSTEMS, INC.
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9027Trees

Definitions

  • Embodiments of the invention relate generally to the field of data storage and more particularly to an efficient structure for storing metadata (data pertaining to data).
  • a conventional data storage device contains an array of disk drives for data storage, a controller for controlling access to the disk array, and a cache memory.
  • the cache memory is used for storing recently accessed data so as to provide quick access to data that is likely to be accessed in the near-term without having to access the disk on every occasion.
  • the storage device first attempts to satisfy the request using the cache, before using the disk array. For example, when a READ operation is referencing data that is already in cache, the data will be returned directly from the cache. For WRITE operations, the data is written into the data cache, replacing previous versions of the same data, if any, within the cache.
  • the storage device typically includes Metadata (MD) that registers all data blocks currently in the cache and, therefore, indicates whether a data block is on the disk or stored in cache. If the data block is in the cache, the MD indicates where the data block is stored in the cache. The MD also indicates the current state of the data block (i.e., whether or not it has been “flushed” to disk).
  • MD Metadata
  • RAM random access memory
  • NVRAM non-volatile RAM
  • the data cache is divided into fixed size ‘slots’, and the MD store is divided into fixed size ‘entries’.
  • the MD may be organized as a table with an implicit association (direct mapping) between the MD entries and the data cache slots. That is, each MD entry is statically associated to a particular data cache slot, and the data block relating to a MD entry is implicitly contained in the data block slot thus associated with the entry.
  • the MD may be organized in a fully associative manner in which each MD entry in the table also includes a pointer to an arbitrary data cache slot.
  • Such organization for the MD has a substantial drawback in that because the MD requires a fixed size (i.e., an entry for each data cache slot), the array controller cannot dynamically divide the NVRAM between the data cache and metadata according to application need.
  • the process of locating a given block address in the MD structure is typically done in one of the two ways.
  • the controller simply searches through the MD table entries until it finds a match. This method may present performance problems because it may require searching a large number of MD entries.
  • the other method of locating a given block address in the MD structure employs a hash function to map groups of block addresses into particular metadata entries. Each block address can be mapped to exactly one entry, but multiple addresses can be mapped to the same entry. A block address field within the entry determines the actual data block being represented by the entry. In the case where the hash function maps every block address to a different entry, a direct mapping results.
  • the hash function approach can result in conflicts, where multiple heavily-used block addresses that happen to be mapped to the same MD entry keep forcing their corresponding data blocks to be evicted from the data cache (because the MD entry can only describe one particular data block at any time), even if there is plenty of free space left in the data cache.
  • a direct-mapped hash function eliminates such conflicts, but can waste a lot of metadata store, since a entry must be reserved for each VBA at all times, regardless of whether it is ever used or not.
  • Typical storage devices divide a disk into a number of discrete storage areas known as virtual logical units (VLUs) each of which supports an independent virtual block address (VBA) space. Therefore every user data block in the array is uniquely identified by referenced to a particular VLU and a VBA.
  • VLUs virtual logical units
  • VBA virtual block address
  • the MD store need not be partitioned, but the entire MD store may be included in one table where each may represent any user data block from any VLU.
  • the lookup function may be based on a combination of both the VLU# and VBA. If such an implementation employs a hash function, it may suffer from another kind of conflict where the same VBA from different VLUs force one another out of the cache.
  • An embodiment of the present invention provides a MD tree structure comprising a plurality of nodes (slabs), each node containing a MD table.
  • Each of the MD tables has a plurality of entries.
  • Each of the entries in the MD table represents a contiguous range of block addresses and contains a pointer to a random access memory slot storing a data block corresponding to the block address, or an indicator to indicate that the corresponding data block is not stored in a random access memory slot.
  • Each MD table also contains a block address range indicator to indicate the continuous range of block address, and at least one pointer to point to any parent or child nodes.
  • FIG. 1 illustrates a storage device having a MD tree structure in accordance with one embodiment of the present invention
  • FIGS. 2A and 2B illustrate a MD structure organized as a tree of slabs in accordance with embodiments of the present invention
  • FIG. 3 illustrates the contents of each slab of a MD tree structure in accordance with one embodiment
  • FIG. 4 illustrates a process by which the NVRAM is dynamically allocated between the data cache and MD tree structure in response to system requirements in accordance with one embodiment.
  • An embodiment of the present invention provides a MD tree structure having a plurality of nodes (slabs), each node containing a MD table.
  • Each of the MD tables has a plurality of entries.
  • Each of the entries in the MD table represents a contiguous range of block addresses and contains a pointer to a cache slot storing a data block corresponding to the block address, or an indicator to indicate that the corresponding data block is not stored in a NVRAM cache slot.
  • Each MD table also contains a block address range indicator to indicate the contiguous range of block addresses, and at least one pointer to point to any parent or child nodes.
  • the pointer of each MD entry may point to either a cache slot or a disk address depending on whether the data is in cache or on disk. For such an embodiment, portions of the MD store that are used relatively infrequently may be stored to disk.
  • each cache slot is an integral multiple of the size of each MD slab. Such organization allows for a dynamic and efficient allocation of the NVRAM between the data cache and the MD store.
  • a MD tree structure is created for each VLU to avoid conflicting MD entries.
  • the MD store need not be statically partitioned among the VLUs thus allowing efficient use of the NVRAM.
  • An intended advantage of one embodiment of the present invention is to reduce MD search time through use of a MD tree structure allowing a logarithmic (as opposed to linear) MD search. Another intended advantage of one embodiment of the present invention is reduce MD search time by including a contiguous range of block addresses in each slab thereby allowing a simple offset of the slab's block address range to locate the desired block addresses. Another intended advantage of one embodiment of the present invention is to provide for the dynamic adjustment of the MD slab size and/or the number of MD slabs installed in the MD tree structure (and hence the amount of NVRAM allocated for MD storage) to allow efficient allocation of NVRAM between the MD and the cache.
  • FIG. 1 illustrates a storage device having a MD tree structure in accordance with one embodiment of the present invention.
  • Storage device 100 shown in FIG. 1 includes a number of storage disks shown as storage disks 105 A and 105 B. Each storage disk may be partitioned into a number of VLUs. For example, storage disk 105 A is partitioned into VLUs 1 through n, and storage disk 105 B is partitioned into VLUs n+1 through 2n.
  • the storage disks are coupled to cache 110 , which is located in NVRAM 120 . Also located in NVRAM 120 is the MD tree structure 115 of the present invention. Controller 125 is coupled to the data cache 110 and to the MD tree structure 115 , and through these to the storage disks.
  • the MD tree structure contains a number of nodes where each node is a slab containing a fixed number of MD entries, pointers to parent or child slabs, and the range of block addresses that the slab represents.
  • FIG. 2A illustrates a MD structure organized as a tree of MD slabs in accordance with one embodiment of the present invention.
  • a new MD tree structure is created starting with a root slab. Initially the structure would be vacant, but as data pertaining to the particular VLU is added, the tree is created.
  • MD tree structure 200 A is an “in-progress” tree that illustrates various features of a MD tree structure for one embodiment.
  • MD tree structure 200 A includes slabs 201 – 208 each of which is a MD slab representing a standard size region of NVRAM that encompasses a specified contiguous range of VBAs. The size of each slab may be related to the cache line size.
  • a slab with 1000 entries having an addressing capability of 8 M bytes may be implemented. That is, each of the 1000 entries in the slab addresses one cache line containing sixteen 512-byte blocks.
  • Each MD slab of MD tree structure 200 A has a range of 16,000 VBAs.
  • Each MD slab contains the MD entries for the specified range, for example, in a sequential or directly-addressable manner, as described above, in which each MD entry in the table also includes a pointer to an arbitrary data cache slot.
  • the VBA 32,050 is represented by the fourth MD entry within the MD slab having a VBA range on 32,000–47,999.
  • the specific data block corresponding to VBA 32,050 is stored in the third data block in the cache slot located via the MD entry.
  • the MD tree structure in accordance with one embodiment, is organized using conventional search-tree properties. For example, the VBA range represented by a slab's left child is always lower then the range of the slab itself, and the VBA range represented by the slab's right child is always higher then that of the slab itself. As shown in FIG. 2A , slab 201 has VBA range 96,000–111,999, while its left child slab, slab 202 has a lower range (i.e., 32,000–47,999) and its right child slab, slab 203 has a higher range (i.e., 112,000–127,999).
  • FIG. 3 illustrates the contents of each slab of MD tree structure 200 A in accordance with one embodiment.
  • FIG. 3 illustrates the contents of slab 203 .
  • Each slab contains a VBA range 305 and a parent slab pointer 310 .
  • Each slab may also contain one or more child slab pointers 315 . Note: If no child exists, the child slab pointer would be null.
  • Each slab also contains MD entries 320 .
  • the VBA range 305 for slab 203 is 112,000–127,999; the parent slab pointer 310 points to slab 201 and indicates the range of slab 201 as 96,000–111,999; the child slab pointer 315 points to slab 207 , and indicates a range of 144,000–159,999; and the MD entries 320 include the MD entries for VBAs 112,000–127,999.
  • the MD tree structure of the present invention decreases the MD search time in several ways. For example, because the MD is organized as a tree, the search is logarithmic (as opposed to the linear search of a conventional MD table). For example, referring again to FIG. 2A , suppose the MD search is for a range of VBAs starting with VBA 134,400 through VBA 134,559. Then starting at root slab 201 , of MD tree structure 200 A, the range is checked. Since the VBA range of interest is in a higher range, the search proceeds to the right child of the root slab (i.e., slab 203 ) and its range is checked.
  • the search proceeds to the right child of slab 203 , namely, slab 207 , and its range is checked.
  • Slab 207 has a range of 144,000–159,999. Since the VBA range of interest is included in a lower range, the search proceeds to the left child of slab 207 , namely slab 208 .
  • the range of slab 208 is 128,000–143,999, which includes the VBA range of interest. Therefore, the organization of the MD entries in a MD tree structure renders a search of all the MD entries unnecessary.
  • the MD tree structure of the present invention need not be as large as a conventional MD table, as it need only contain slabs that encompass actual cache slots and not all potential cache slots.
  • a further way in which the MD tree structure of the present invention reduces MD search time is that the MD entries represent a contiguous range of VBAs. This means that once the slab representing the corresponding VBA range is found, an offset within the slab can be calculated and the corresponding range of VBAs retrieved. For example, once slab 208 , containing the VBA range of interest 134,400–134,559 has been determined, it is further determined that VBAs 134,400–134,559 are represented by entries 401 through the 410 (i.e., entries 210 ) of slab 208 . The MD of these entries are then retrieved. The MD entries contain either a pointer to a data cache slot containing the requested data block, or an indication that the requested data block is currently not in the data cache.
  • FIG. 2B illustrates the addition of a MD slab to the MD tree structure in accordance with one embodiment.
  • a MD search is conducted for a range of VBAs that is not in the data cache, the search will not yield a corresponding MD slab.
  • a MD search for a VBA range of 67,200–67,520 will not yield a corresponding MD slab because none of the MD slabs within MD tree structure 200 A contain this range of VBAs.
  • the array controller decides to bring the data block into cache (in the case of a READ operation, or allow the requestor to deposit data into cache in the case of a WRITE), it allocates a new slab.
  • MD tree structure 200 B includes slab 209 , which has been inserted into the MD tree structure in response to a data access request.
  • Slab 209 has a range of 64,000–79,999, which includes the VBA range of interest.
  • the new slab is added to the tree structure, it is initialized with the appropriate VBA range, parent/child pointers, and MD entries.
  • the slab is then linked into the proper location in the tree of slabs. For example, slab 209 has a higher range than that of slab 205 , and therefore it could be inserted as a right child to slab 205 . Since slab 209 has a lower range than that of slab 206 , slab 209 could instead be inserted as a left child of slab 206 .
  • the entire MD tree structure may be reconfigured to provide a “balanced” tree structure, with four slabs branching to the left of the root slab and four slabs branching to the right of the root slab.
  • the controller may then allocate a data cache slot for the requested data block, and place the corresponding pointers into the MD entries at the appropriate offset within the newly allocated MD slab. Note that a slab need not always be fully populated. Some of the entries in a slab may contain a NULL pointer. In that case, the corresponding VBA is not currently in the cache.
  • the controller may allocate a data cache slot and fetch the corresponding data block from disk (or accept it from a host WRITE command), and then fill the entry with the cache slot pointer.
  • MD slabs containing VBAs for data that is no longer stored in cache may be deleted from the MD tree structure.
  • deletions result in a reorganization of the MD tree structure in order to maintain a balanced tree structure.
  • the amount of NVRAM allocated for the MD tree structure may be determined based upon system requirements and data access patterns.
  • the size of a data cache slot is chosen to be an integral multiple of the size of a metadata slab. This provides the ability to dynamically allocate the use of NVRAM between the data cache and MD tree structure in response to system requirements. That is, a region of NVRAM can be used either as one data cache slot, or several metadata slabs, as the request traffic changes. Note that there is no longer a strict one-to-one match between metadata entries and data cache slots. Rather, there is only a one-to-one match between valid metadata entries and actually used data cache slots. Therefore, any available free slots in the NVRAM can be used by any VLU.
  • FIG. 4 illustrates a process by which the NVRAM is dynamically allocated between the data cache and MD tree structure in response to system requirements in accordance with one embodiment.
  • Process 400 begins at operation 405 in which system requirements and data access patterns are analyzed. Such requirements may include a balancing between MD search time and available NVRAM.
  • a MD slab size for the MD tree structure is determined based upon the analysis of the system requirements and data access patterns. For example, if the system requirement is relatively short MD search times, then the MD slabs may be made relatively large thus reducing MD search time. will be reduced. However, large MD slabs imply a greater amount of unused MD entries (i.e., wasted NVRAM space). Therefore, if the system requirement is efficient use of NVRAM, then the MD slabs may be made relatively small even though this will lead to longer MD search times and a corresponding increase in the use of processing resources.
  • the data access patterns may be considered at operation 405 .
  • analysis of the data access patterns may indicate that only a relatively small amount of data is being accessed regularly. This implies that a small data cache may be sufficient, allowing for larger MD slabs and hence reduced MD search times.
  • the available NVRAM is dynamically allocated between the MD tree structure and the data cache. Because systems typically have a limited and fixed amount of NVRAM, dynamic allocation allows for more efficient use of the NVRAM.
  • process 400 To further illustrate process 400 , the following examples of dynamic allocation of NVRAM are provided for various embodiments of the invention.
  • a new VLU when a new VLU is created, its data access patterns are predicted, perhaps based upon the data access patterns of existing VLUs.
  • the system then chooses an appropriate MD slab size. For example, if the user expects that there is very little spatial locality of reference in the VLU, the user may instruct the system to choose a smaller MD slab size. Once the MD slab size is chosen, it may be kept constant for that entire VLU MD tree structure.
  • the system may use data access patterns to dynamically choose the size of that particular MD slab. For example, if the user observes very little spatial locality of reference for this range of VBAs in the VLU, a smaller MD slab size may be chosen.
  • a single VLU MD tree structure may contain MD slabs of varying sizes. This does not create a problem because each MD slab already contains the description of the exact range of VBAs it represents.
  • the system may use data access patterns to dynamically determine the number of MD slabs will be installed in the VLU at any time. For example, in an embodiment in which some of the MD slabs are stored on the disk, as described above, the system determines what portion of the total number of MD slabs are stored on disk and what portion are stored in NVRAM. Additionally, or alternatively, the system may dynamically decide to keep more MD slabs and fewer data slots, or vice versa.
  • Embodiments of the invention may be applied to provide for faster MD searches and more efficient use NVRAM as discussed above and to avoid the drawbacks of conventional MD organization schemes.
  • a MD search using the MD tree structure in accordance with one embodiment results in improved efficiency as an MD entry need not be reserved for every VBA and there are no conflicts resulting from VBAs mapped to the same MD entry forcing corresponding data blocks from the data cache. Performance is improved over conventional MD searches (e.g., table-walk method), as the number of entries is greatly reduced. Note that some entries may still be ‘wasted’ because a new slab must be allocated even if only one of the VBAs within the corresponding range is accessed (i.e., the remaining entries may be NULL). However, it is estimated that due to locality of reference, there will be few scenarios where only a very small number of entries within every slab is accessed.
  • an MD tree structure may be initiated for each available VLU. This organization offers the benefits of non-interference between VLUs (i.e., no conflicts for MD entries). Moreover, because the MD store is not statically portioned among the VLUs, the available NVRAM can be utilized efficiently, such that a busy VLU can benefit from using more of the MD store, and if necessary, more of the data cache. In another scenario, a VLU demonstrating a relatively high spatial locality of reference may be allocated relatively more data cache slots, but only a small amount of the MD store, while a relatively less busy VLU may be allocated a greater amount of MD store, but only as many data cache slots as needed.
  • the invention includes various operations. It will be apparent to those skilled in the art that the operations of the invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the operations. Alternatively, the steps may be performed by a combination of hardware and software.
  • the invention may be provided as a computer program product that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process according to the invention.
  • the machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks.
  • ROMs Read Only Memory
  • RAMs Random Access Memory
  • EPROMs programmable read-only memory
  • EEPROMs electrically erasable programmable read-only memory
  • magnet or optical cards flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.
  • the invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication cell (e.g., a modem or network connection).
  • a communication cell e.g., a modem or network connection

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

A metadata tree structure having a plurality of nodes (slabs), each node containing a MD table. Each of the MD tables has a plurality of entries. Each of the entries in the MD tables represents a contiguous range of block addresses and contains a pointer to a cache slot storing a date block corresponding to the block address, or an indicator to indicate that the corresponding data block is not stored in a NVRAM cache slot. Each MD table also contains a block address range indicator to indicate the contiguous range of block addresses, and at least one pointer to point to any parent or child nodes. In an alternative embodiment, the pointer of each MD entry may point to a disk address if the data is not in cache. For such an embodiment, portions of the MD store may be stored to disk.

Description

FIELD
Embodiments of the invention relate generally to the field of data storage and more particularly to an efficient structure for storing metadata (data pertaining to data).
BACKGROUND
A conventional data storage device contains an array of disk drives for data storage, a controller for controlling access to the disk array, and a cache memory. The cache memory is used for storing recently accessed data so as to provide quick access to data that is likely to be accessed in the near-term without having to access the disk on every occasion. When a data access request is received, the storage device first attempts to satisfy the request using the cache, before using the disk array. For example, when a READ operation is referencing data that is already in cache, the data will be returned directly from the cache. For WRITE operations, the data is written into the data cache, replacing previous versions of the same data, if any, within the cache. Since a particular file or block of data may be located on the disk or in the cache, the storage device typically includes Metadata (MD) that registers all data blocks currently in the cache and, therefore, indicates whether a data block is on the disk or stored in cache. If the data block is in the cache, the MD indicates where the data block is stored in the cache. The MD also indicates the current state of the data block (i.e., whether or not it has been “flushed” to disk).
Since fast access is required to both the data cache and the MD store, both are typically stored in random access memory (RAM). Because it is important that the data cache and the MD store not be lost in the event of an unexpected power failure, the RAM is typically non-volatile RAM (NVRAM). Because NVRAM is expensive, only a limited amount is available in a storage device. This means that the more NVRAM is used to store MD, the less is available for actual data.
Typically, the data cache is divided into fixed size ‘slots’, and the MD store is divided into fixed size ‘entries’. In conventional design, there is typically a one-to-one matching between slots and entries. Typically the MD may be organized as a table with an implicit association (direct mapping) between the MD entries and the data cache slots. That is, each MD entry is statically associated to a particular data cache slot, and the data block relating to a MD entry is implicitly contained in the data block slot thus associated with the entry. Alternatively, the MD may be organized in a fully associative manner in which each MD entry in the table also includes a pointer to an arbitrary data cache slot. When a data access request for a particular data block is received at the storage device, the array controller looks in the MD structure to find an entry that contains the block address. The entry contains the pointer to the data cache slot containing the corresponding data block.
Such organization for the MD has a substantial drawback in that because the MD requires a fixed size (i.e., an entry for each data cache slot), the array controller cannot dynamically divide the NVRAM between the data cache and metadata according to application need.
The process of locating a given block address in the MD structure is typically done in one of the two ways. One is that, the controller simply searches through the MD table entries until it finds a match. This method may present performance problems because it may require searching a large number of MD entries. The other method of locating a given block address in the MD structure employs a hash function to map groups of block addresses into particular metadata entries. Each block address can be mapped to exactly one entry, but multiple addresses can be mapped to the same entry. A block address field within the entry determines the actual data block being represented by the entry. In the case where the hash function maps every block address to a different entry, a direct mapping results. The hash function approach can result in conflicts, where multiple heavily-used block addresses that happen to be mapped to the same MD entry keep forcing their corresponding data blocks to be evicted from the data cache (because the MD entry can only describe one particular data block at any time), even if there is plenty of free space left in the data cache. A direct-mapped hash function eliminates such conflicts, but can waste a lot of metadata store, since a entry must be reserved for each VBA at all times, regardless of whether it is ever used or not.
Typical storage devices divide a disk into a number of discrete storage areas known as virtual logical units (VLUs) each of which supports an independent virtual block address (VBA) space. Therefore every user data block in the array is uniquely identified by referenced to a particular VLU and a VBA. The MD structure must therefore include VLU information to be able to support such multi-VLU configurations.
This need may be facilitated by logically dividing the MD store into separate tables for each VLU. Given a block address (VLU#, VBA), the array controller performs the MD lookup in the appropriate partition of the MD store. However, partitioning the MD store can result in inefficient use of the NVRAM. For example, a busy VLU cannot make use of the MD entries (and, consequently, the one-to-one-matched data cache slots) allocated to idle VLU's.
Alternatively, the MD store need not be partitioned, but the entire MD store may be included in one table where each may represent any user data block from any VLU. In such case, the lookup function may be based on a combination of both the VLU# and VBA. If such an implementation employs a hash function, it may suffer from another kind of conflict where the same VBA from different VLUs force one another out of the cache.
SUMMARY
An embodiment of the present invention provides a MD tree structure comprising a plurality of nodes (slabs), each node containing a MD table. Each of the MD tables has a plurality of entries. Each of the entries in the MD table represents a contiguous range of block addresses and contains a pointer to a random access memory slot storing a data block corresponding to the block address, or an indicator to indicate that the corresponding data block is not stored in a random access memory slot. Each MD table also contains a block address range indicator to indicate the continuous range of block address, and at least one pointer to point to any parent or child nodes.
Other features and advantages of embodiments of the present invention will be apparent from the accompanying drawings, and from the detailed description, that follows below.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
FIG. 1 illustrates a storage device having a MD tree structure in accordance with one embodiment of the present invention;
FIGS. 2A and 2B illustrate a MD structure organized as a tree of slabs in accordance with embodiments of the present invention;
FIG. 3 illustrates the contents of each slab of a MD tree structure in accordance with one embodiment; and
FIG. 4 illustrates a process by which the NVRAM is dynamically allocated between the data cache and MD tree structure in response to system requirements in accordance with one embodiment.
DETAILED DESCRIPTION
Overview
An embodiment of the present invention provides a MD tree structure having a plurality of nodes (slabs), each node containing a MD table. Each of the MD tables has a plurality of entries. Each of the entries in the MD table represents a contiguous range of block addresses and contains a pointer to a cache slot storing a data block corresponding to the block address, or an indicator to indicate that the corresponding data block is not stored in a NVRAM cache slot. Each MD table also contains a block address range indicator to indicate the contiguous range of block addresses, and at least one pointer to point to any parent or child nodes.
In an alternative embodiment, the pointer of each MD entry may point to either a cache slot or a disk address depending on whether the data is in cache or on disk. For such an embodiment, portions of the MD store that are used relatively infrequently may be stored to disk.
In one embodiment, the size of each cache slot is an integral multiple of the size of each MD slab. Such organization allows for a dynamic and efficient allocation of the NVRAM between the data cache and the MD store.
In one embodiment, a MD tree structure is created for each VLU to avoid conflicting MD entries. In such an embodiment, the MD store need not be statically partitioned among the VLUs thus allowing efficient use of the NVRAM.
An intended advantage of one embodiment of the present invention is to reduce MD search time through use of a MD tree structure allowing a logarithmic (as opposed to linear) MD search. Another intended advantage of one embodiment of the present invention is reduce MD search time by including a contiguous range of block addresses in each slab thereby allowing a simple offset of the slab's block address range to locate the desired block addresses. Another intended advantage of one embodiment of the present invention is to provide for the dynamic adjustment of the MD slab size and/or the number of MD slabs installed in the MD tree structure (and hence the amount of NVRAM allocated for MD storage) to allow efficient allocation of NVRAM between the MD and the cache.
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.
Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
FIG. 1 illustrates a storage device having a MD tree structure in accordance with one embodiment of the present invention. Storage device 100 shown in FIG. 1 includes a number of storage disks shown as storage disks 105A and 105B. Each storage disk may be partitioned into a number of VLUs. For example, storage disk 105A is partitioned into VLUs 1 through n, and storage disk 105B is partitioned into VLUs n+1 through 2n. The storage disks are coupled to cache 110, which is located in NVRAM 120. Also located in NVRAM 120 is the MD tree structure 115 of the present invention. Controller 125 is coupled to the data cache 110 and to the MD tree structure 115, and through these to the storage disks. The MD tree structure contains a number of nodes where each node is a slab containing a fixed number of MD entries, pointers to parent or child slabs, and the range of block addresses that the slab represents.
Metadata Tree Structure Organization
FIG. 2A illustrates a MD structure organized as a tree of MD slabs in accordance with one embodiment of the present invention. In one embodiment, as each VLU is created within a storage disk, a new MD tree structure is created starting with a root slab. Initially the structure would be vacant, but as data pertaining to the particular VLU is added, the tree is created. MD tree structure 200A is an “in-progress” tree that illustrates various features of a MD tree structure for one embodiment. MD tree structure 200A includes slabs 201208 each of which is a MD slab representing a standard size region of NVRAM that encompasses a specified contiguous range of VBAs. The size of each slab may be related to the cache line size. For example, for a system having a cache line with a capacity of 8 K bytes (i.e., sixteen 512-byte blocks), a slab with 1000 entries having an addressing capability of 8 M bytes may be implemented. That is, each of the 1000 entries in the slab addresses one cache line containing sixteen 512-byte blocks. Each MD slab of MD tree structure 200A has a range of 16,000 VBAs. Each MD slab contains the MD entries for the specified range, for example, in a sequential or directly-addressable manner, as described above, in which each MD entry in the table also includes a pointer to an arbitrary data cache slot. For example, for a slab having 16,000 VBAs, the VBA 32,050 is represented by the fourth MD entry within the MD slab having a VBA range on 32,000–47,999. The specific data block corresponding to VBA 32,050 is stored in the third data block in the cache slot located via the MD entry.
The MD tree structure, in accordance with one embodiment, is organized using conventional search-tree properties. For example, the VBA range represented by a slab's left child is always lower then the range of the slab itself, and the VBA range represented by the slab's right child is always higher then that of the slab itself. As shown in FIG. 2A, slab 201 has VBA range 96,000–111,999, while its left child slab, slab 202 has a lower range (i.e., 32,000–47,999) and its right child slab, slab 203 has a higher range (i.e., 112,000–127,999).
FIG. 3 illustrates the contents of each slab of MD tree structure 200A in accordance with one embodiment. For example, FIG. 3 illustrates the contents of slab 203. Each slab contains a VBA range 305 and a parent slab pointer 310. Each slab may also contain one or more child slab pointers 315. Note: If no child exists, the child slab pointer would be null. Each slab also contains MD entries 320. For example, the VBA range 305 for slab 203 is 112,000–127,999; the parent slab pointer 310 points to slab 201 and indicates the range of slab 201 as 96,000–111,999; the child slab pointer 315 points to slab 207, and indicates a range of 144,000–159,999; and the MD entries 320 include the MD entries for VBAs 112,000–127,999.
The MD tree structure of the present invention decreases the MD search time in several ways. For example, because the MD is organized as a tree, the search is logarithmic (as opposed to the linear search of a conventional MD table). For example, referring again to FIG. 2A, suppose the MD search is for a range of VBAs starting with VBA 134,400 through VBA 134,559. Then starting at root slab 201, of MD tree structure 200A, the range is checked. Since the VBA range of interest is in a higher range, the search proceeds to the right child of the root slab (i.e., slab 203) and its range is checked. Since the VBA range of interest is in a higher range, the search proceeds to the right child of slab 203, namely, slab 207, and its range is checked. Slab 207 has a range of 144,000–159,999. Since the VBA range of interest is included in a lower range, the search proceeds to the left child of slab 207, namely slab 208. The range of slab 208 is 128,000–143,999, which includes the VBA range of interest. Therefore, the organization of the MD entries in a MD tree structure renders a search of all the MD entries unnecessary. Moreover, the MD tree structure of the present invention need not be as large as a conventional MD table, as it need only contain slabs that encompass actual cache slots and not all potential cache slots.
A further way in which the MD tree structure of the present invention reduces MD search time is that the MD entries represent a contiguous range of VBAs. This means that once the slab representing the corresponding VBA range is found, an offset within the slab can be calculated and the corresponding range of VBAs retrieved. For example, once slab 208, containing the VBA range of interest 134,400–134,559 has been determined, it is further determined that VBAs 134,400–134,559 are represented by entries 401 through the 410 (i.e., entries 210) of slab 208. The MD of these entries are then retrieved. The MD entries contain either a pointer to a data cache slot containing the requested data block, or an indication that the requested data block is currently not in the data cache.
Slab Insertion/Deletion
FIG. 2B illustrates the addition of a MD slab to the MD tree structure in accordance with one embodiment. If a MD search is conducted for a range of VBAs that is not in the data cache, the search will not yield a corresponding MD slab. For example, referring again to FIG. 2A, a MD search for a VBA range of 67,200–67,520 will not yield a corresponding MD slab because none of the MD slabs within MD tree structure 200A contain this range of VBAs. At this point, if the array controller decides to bring the data block into cache (in the case of a READ operation, or allow the requestor to deposit data into cache in the case of a WRITE), it allocates a new slab. MD tree structure 200B includes slab 209, which has been inserted into the MD tree structure in response to a data access request. Slab 209 has a range of 64,000–79,999, which includes the VBA range of interest. Once the new slab is added to the tree structure, it is initialized with the appropriate VBA range, parent/child pointers, and MD entries. The slab is then linked into the proper location in the tree of slabs. For example, slab 209 has a higher range than that of slab 205, and therefore it could be inserted as a right child to slab 205. Since slab 209 has a lower range than that of slab 206, slab 209 could instead be inserted as a left child of slab 206. Alternatively, the entire MD tree structure may be reconfigured to provide a “balanced” tree structure, with four slabs branching to the left of the root slab and four slabs branching to the right of the root slab.
The controller may then allocate a data cache slot for the requested data block, and place the corresponding pointers into the MD entries at the appropriate offset within the newly allocated MD slab. Note that a slab need not always be fully populated. Some of the entries in a slab may contain a NULL pointer. In that case, the corresponding VBA is not currently in the cache. The controller may allocate a data cache slot and fetch the corresponding data block from disk (or accept it from a host WRITE command), and then fill the entry with the cache slot pointer.
MD slabs containing VBAs for data that is no longer stored in cache may be deleted from the MD tree structure. In one embodiment, such deletions result in a reorganization of the MD tree structure in order to maintain a balanced tree structure.
Dynamic Allocation of NVRAM
The amount of NVRAM allocated for the MD tree structure, and hence, the amount remaining for the data cache, may be determined based upon system requirements and data access patterns. For example, as noted above, in one embodiment, the size of a data cache slot is chosen to be an integral multiple of the size of a metadata slab. This provides the ability to dynamically allocate the use of NVRAM between the data cache and MD tree structure in response to system requirements. That is, a region of NVRAM can be used either as one data cache slot, or several metadata slabs, as the request traffic changes. Note that there is no longer a strict one-to-one match between metadata entries and data cache slots. Rather, there is only a one-to-one match between valid metadata entries and actually used data cache slots. Therefore, any available free slots in the NVRAM can be used by any VLU.
FIG. 4 illustrates a process by which the NVRAM is dynamically allocated between the data cache and MD tree structure in response to system requirements in accordance with one embodiment. Process 400 begins at operation 405 in which system requirements and data access patterns are analyzed. Such requirements may include a balancing between MD search time and available NVRAM.
At operation 410, a MD slab size for the MD tree structure is determined based upon the analysis of the system requirements and data access patterns. For example, if the system requirement is relatively short MD search times, then the MD slabs may be made relatively large thus reducing MD search time. will be reduced. However, large MD slabs imply a greater amount of unused MD entries (i.e., wasted NVRAM space). Therefore, if the system requirement is efficient use of NVRAM, then the MD slabs may be made relatively small even though this will lead to longer MD search times and a corresponding increase in the use of processing resources.
Additionally, or alternatively, the data access patterns may be considered at operation 405. For example, analysis of the data access patterns may indicate that only a relatively small amount of data is being accessed regularly. This implies that a small data cache may be sufficient, allowing for larger MD slabs and hence reduced MD search times.
At operation 415, the available NVRAM is dynamically allocated between the MD tree structure and the data cache. Because systems typically have a limited and fixed amount of NVRAM, dynamic allocation allows for more efficient use of the NVRAM.
To further illustrate process 400, the following examples of dynamic allocation of NVRAM are provided for various embodiments of the invention.
For one embodiment, when a new VLU is created, its data access patterns are predicted, perhaps based upon the data access patterns of existing VLUs. The system then chooses an appropriate MD slab size. For example, if the user expects that there is very little spatial locality of reference in the VLU, the user may instruct the system to choose a smaller MD slab size. Once the MD slab size is chosen, it may be kept constant for that entire VLU MD tree structure.
In an alternative embodiment, when a new MD slab is inserted into an existing VLU, the system may use data access patterns to dynamically choose the size of that particular MD slab. For example, if the user observes very little spatial locality of reference for this range of VBAs in the VLU, a smaller MD slab size may be chosen. In such an embodiment, a single VLU MD tree structure may contain MD slabs of varying sizes. This does not create a problem because each MD slab already contains the description of the exact range of VBAs it represents.
In still another embodiment, the system may use data access patterns to dynamically determine the number of MD slabs will be installed in the VLU at any time. For example, in an embodiment in which some of the MD slabs are stored on the disk, as described above, the system determines what portion of the total number of MD slabs are stored on disk and what portion are stored in NVRAM. Additionally, or alternatively, the system may dynamically decide to keep more MD slabs and fewer data slots, or vice versa.
General Matters
Embodiments of the invention may be applied to provide for faster MD searches and more efficient use NVRAM as discussed above and to avoid the drawbacks of conventional MD organization schemes.
A MD search using the MD tree structure in accordance with one embodiment results in improved efficiency as an MD entry need not be reserved for every VBA and there are no conflicts resulting from VBAs mapped to the same MD entry forcing corresponding data blocks from the data cache. Performance is improved over conventional MD searches (e.g., table-walk method), as the number of entries is greatly reduced. Note that some entries may still be ‘wasted’ because a new slab must be allocated even if only one of the VBAs within the corresponding range is accessed (i.e., the remaining entries may be NULL). However, it is estimated that due to locality of reference, there will be few scenarios where only a very small number of entries within every slab is accessed.
For systems supporting multiple VLUs, an MD tree structure may be initiated for each available VLU. This organization offers the benefits of non-interference between VLUs (i.e., no conflicts for MD entries). Moreover, because the MD store is not statically portioned among the VLUs, the available NVRAM can be utilized efficiently, such that a busy VLU can benefit from using more of the MD store, and if necessary, more of the data cache. In another scenario, a VLU demonstrating a relatively high spatial locality of reference may be allocated relatively more data cache slots, but only a small amount of the MD store, while a relatively less busy VLU may be allocated a greater amount of MD store, but only as many data cache slots as needed.
The invention includes various operations. It will be apparent to those skilled in the art that the operations of the invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the operations. Alternatively, the steps may be performed by a combination of hardware and software. The invention may be provided as a computer program product that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process according to the invention. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks. ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, the invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication cell (e.g., a modem or network connection).
While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, but can be practised with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims (27)

1. A method for operating a data storage system, the method comprising:
storing data in one or more cache slots of a random access memory of the data storage system;
storing metadata entries in a tree structure in the random access memory of the data storage system, wherein the metadata tree structure includes a plurality of slabs, each slab comprising a metadata table including a plurality of metadata entries representing a contiguous range of block addresses, each entry including a cache pointer to one of the caches slots storing a data block corresponding to a block address within the contiguous range of block addresses;
storing a block address range indicator in the metadata table of each slab to indicate the contiguous range of block addresses associated with the metadata entries in the slab; and
forming the metadata tree structure by storing at least one slab pointer in the metadata table of each slab, each slab pointer pointing to a parent slab or a child slab in the metadata tree structure.
2. The method of claim 1, wherein each entry includes a cache pointer to one of the caches slots storing a data block corresponding to the block address or an indicator to indicate that the corresponding data block is not stored in a cache slot.
3. The method of claim 1, wherein the random access memory is nonvolatile random access memory.
4. The method of claim 1, wherein a slab size is determined based upon system requirements and anticipated data access patterns.
5. The method of claim 1, wherein a slab size for a particular slab is dynamically determined based upon data access patterns for the particular slab.
6. The method of claim 1, wherein the number of slabs is dynamically determined.
7. The method of claim 2, wherein the indicator to indicate that the corresponding data block is not stored in a cache slot is a disk location storing the corresponding data block.
8. The method of claim 7, wherein a portion of the metadata tree structure is stored in a disk memory.
9. The method of claim 8, wherein the portion of the metadata tree structure that is stored in the disk memory is dynamically determined.
10. A method for operating a data storage system, the method comprising:
analyzing system requirements and data access patterns for the data storage system;
storing data in one or more cache slots of a random access memory of the data storage system;
storing metadata entries in a tree structure in the random access memory of the data storage system, wherein the metadata tree structure includes a plurality of slabs, each slab comprising a metadata table including a plurality of metadata entries representing a contiguous range of block addresses, each entry including a cache pointer to one of the caches slots storing a data block corresponding to a block address within the contiguous range of block addresses;
storing a block address range indicator in the metadata table of each slab to indicate the contiguous range of block addresses associated with the metadata entries in the slab;
storing at least one slab pointer in the metadata table of each slab, each slab pointer pointing to a parent slab or a child slab in the metadata tree structure;
determining a number of metadata entries for the metadata table of each slab based upon the system requirements and data access patterns, wherein a portion of available random access memory allocated to the metadata tree structure based upon the number of metadata entries of the plurality of slabs;
dynamically allocating the portion of the random access memory to the metadata tree structure; and
dynamically allocating a remaining amount of the available random access memory to the data cache slots.
11. The method of claim 10, wherein the block addresses of the contiguous ranges are in sequential order within the slab.
12. The method of claim 10, wherein the available random access memory is nonvolatile random access memory.
13. The method of claim 10, wherein each entry includes a cache pointer to one of the caches slots storing a data block corresponding to the block address or an indicator to indicate that the corresponding data block is not stored in a cache slot.
14. The method of claim 13, wherein the indicator to indicate that the corresponding data block is not stored in a cache slot is a disk location storing the corresponding data block.
15. The method of claim 14, wherein a portion of the metadata tree structure is stored in a disk memory.
16. The method of claim 15, wherein the portion of the metadata tree structure that is stored in the disk memory is dynamically determined.
17. A machine-readable storage medium having one or more executable instructions stored thereon, which when executed by a digital processing system, cause the digital processing system to perform a method, the method comprising:
analyzing system requirements and data access patterns for the data storage system;
storing data in one or more cache slots of a random access memory of the data storage system;
storing metadata entries in a tree structure in the random access memory of the data storage system, wherein the metadata tree structure includes a plurality of slabs, each slab comprising a metadata table including a plurality of metadata entries representing a contiguous range of block addresses, each entry including a cache pointer to one of the caches slots storing a data block corresponding to a block address within the contiguous range of block addresses;
storing a block address range indicator in the metadata table of each slab to indicate the contiguous range of block addresses associated with the metadata entries in the slab;
storing at least one slab pointer in the metadata table of each slab, each slab pointer pointing to a parent slab or a child slab in the metadata tree structure;
determining a number of metadata entries for the metadata table of each slab based upon the system requirements and data access patterns, wherein a portion of available random access memory allocated to the metadata tree structure based upon the number of metadata entries of the plurality of slabs;
dynamically allocating the portion of the random access memory to the metadata tree structure; and
dynamically allocating a remaining amount of the available random access memory to the data cache slots.
18. The machine-readable storage medium of claim 17, wherein the block addresses of the contiguous ranges are in sequential order within the slab.
19. The machine-readable storage medium of claim 17, wherein the available random access memory is nonvolatile random access memory.
20. The machine-readable storage medium of claim 18, wherein each entry includes a cache pointer to one of the caches slots storing a data block corresponding to the block address or an indicator to indicate that the corresponding data block is not stored in a cache slot.
21. The machine-readable storage medium of claim 20, wherein the indicator to indicate that the corresponding data block is not stored in a cache slot is a disk location storing the corresponding data block.
22. The machine-readable storage medium of claim 21, wherein a portion of the metadata tree structure is stored in a disk memory.
23. The machine-readable storage medium of claim 22, wherein the portion of the metadata tree structure that is stored in the disk memory is dynamically determined.
24. A data storage system comprising:
a processing system; and
a memory, coupled to the processing system, characterized in that the memory has stored therein instructions which, when executed by the processing system, cause the processing system to:
analyze system requirements and data access patterns for the data storage system;
store data in one or more cache slots of a random access memory of the data storage system;
store metadata entries in a tree structure in the random access memory of the data storage system, wherein the metadata tree structure includes a plurality of slabs, each slab comprising a metadata table including a plurality of metadata entries representing a contiguous range of block addresses, each entry including a cache pointer to one of the caches slots storing a data block corresponding to a block address within the contiguous range of block addresses;
store a block address range indicator in the metadata table of each slab to indicate the contiguous range of block addresses associated with the metadata entries in the slab;
store at least one slab pointer in the metadata table of each slab, each slab pointer pointing to a parent slab or a child slab in the metadata tree structure;
determine a number of metadata entries for the metadata table of each slab based upon the system requirements and data access patterns, wherein a portion of available random access memory allocated to the metadata tree structure based upon the number of metadata entries of the plurality of slabs;
dynamically allocate the portion of the random access memory to the metadata tree structure; and
dynamically allocate a remaining amount of the available random access memory to the data cache slots.
25. The data storage system of claim 24, wherein the block addresses of the contiguous ranges are in sequential order within the slab.
26. The data storage system of claim 24, wherein the available random access memory is nonvolatile random access memory.
27. The method of claim 1, wherein the block addresses of the contiguous ranges are in sequential order within the slab.
US10/261,545 2002-09-30 2002-09-30 Memory-efficient metadata organization in a storage array Expired - Lifetime US7127465B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/261,545 US7127465B2 (en) 2002-09-30 2002-09-30 Memory-efficient metadata organization in a storage array

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/261,545 US7127465B2 (en) 2002-09-30 2002-09-30 Memory-efficient metadata organization in a storage array

Publications (2)

Publication Number Publication Date
US20040064463A1 US20040064463A1 (en) 2004-04-01
US7127465B2 true US7127465B2 (en) 2006-10-24

Family

ID=32030016

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/261,545 Expired - Lifetime US7127465B2 (en) 2002-09-30 2002-09-30 Memory-efficient metadata organization in a storage array

Country Status (1)

Country Link
US (1) US7127465B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100082919A1 (en) * 2008-09-26 2010-04-01 Micron Technology, Inc. Data streaming for solid-state bulk storage devices
US9043334B2 (en) 2012-12-26 2015-05-26 Industrial Technology Research Institute Method and system for accessing files on a storage system
CN111125449A (en) * 2019-12-24 2020-05-08 腾讯科技(深圳)有限公司 Object information storage method, device and storage medium
US10860738B2 (en) 2018-01-30 2020-12-08 Hewlett Packard Enterprise Development Lp Augmented metadata and signatures for objects in object stores
US20240403370A1 (en) * 2023-06-02 2024-12-05 Dell Products L.P. Support for i/o with signature from initiator

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6978353B2 (en) * 2002-10-18 2005-12-20 Sun Microsystems, Inc. Low overhead snapshot in a storage array using a tree-of-slabs metadata
US7240172B2 (en) 2003-02-07 2007-07-03 Sun Microsystems, Inc. Snapshot by deferred propagation
US20050138011A1 (en) * 2003-12-23 2005-06-23 Royer Robert J.Jr. Meta-data storage and access techniques
US7516121B2 (en) 2004-06-23 2009-04-07 Oracle International Corporation Efficient evaluation of queries using translation
US20060047714A1 (en) * 2004-08-30 2006-03-02 Mendocino Software, Inc. Systems and methods for rapid presentation of historical views of stored data
US7664983B2 (en) * 2004-08-30 2010-02-16 Symantec Corporation Systems and methods for event driven recovery management
US7363316B2 (en) 2004-08-30 2008-04-22 Mendocino Software, Inc. Systems and methods for organizing and mapping data
US7484052B2 (en) * 2005-05-03 2009-01-27 International Business Machines Corporation Distributed address arbitration scheme for symmetrical multiprocessor system
US7581064B1 (en) * 2006-04-24 2009-08-25 Vmware, Inc. Utilizing cache information to manage memory access and cache utilization
US7434002B1 (en) * 2006-04-24 2008-10-07 Vmware, Inc. Utilizing cache information to manage memory access and cache utilization
CN101170416B (en) * 2006-10-26 2012-01-04 阿里巴巴集团控股有限公司 Network data storage system and data access method
US9940345B2 (en) 2007-01-10 2018-04-10 Norton Garfinkle Software method for data storage and retrieval
US20090150355A1 (en) * 2007-11-28 2009-06-11 Norton Garfinkle Software method for data storage and retrieval
KR20110139956A (en) * 2010-06-24 2011-12-30 삼성전자주식회사 Data storage and data management methods for recovering mapping tables
CN105207793B (en) * 2014-05-30 2018-10-26 广州亿阳信息技术有限公司 A kind of acquisition methods and system of tree topology interior joint information
US11567972B1 (en) * 2016-06-30 2023-01-31 Amazon Technologies, Inc. Tree-based format for data storage
US10430285B2 (en) * 2017-02-17 2019-10-01 International Business Machines Corporation Backing up metadata
CN112800067B (en) * 2021-02-20 2023-06-20 成都佰维存储科技有限公司 Range query method, range query device, computer-readable storage medium and electronic device
CN117150086B (en) * 2023-09-12 2024-03-22 北京云枢创新软件技术有限公司 Hierarchical tree-based child node generation method, electronic equipment and medium

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044367A (en) * 1996-08-02 2000-03-28 Hewlett-Packard Company Distributed I/O store
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US6484186B1 (en) 2000-02-15 2002-11-19 Novell, Inc. Method for backing up consistent versions of open files
US6532479B2 (en) 1998-05-28 2003-03-11 Oracle Corp. Data replication for front office automation
US20030070036A1 (en) * 2001-09-28 2003-04-10 Gorobets Sergey Anatolievich Memory system for data storage and retrieval
US20030140210A1 (en) * 2001-12-10 2003-07-24 Richard Testardi Dynamic and variable length extents
US6606629B1 (en) * 2000-05-17 2003-08-12 Lsi Logic Corporation Data structures containing sequence and revision number metadata used in mass storage data integrity-assuring technique
US20040062106A1 (en) * 2002-09-27 2004-04-01 Bhashyam Ramesh System and method for retrieving information from a database
US20040078533A1 (en) 2002-10-18 2004-04-22 Lee Whay Sing Low overhead snapshot in a storage array using a tree-of-slabs metadata
US6898688B2 (en) * 2001-12-28 2005-05-24 Storage Technology Corporation Data management appliance

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044367A (en) * 1996-08-02 2000-03-28 Hewlett-Packard Company Distributed I/O store
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US6532479B2 (en) 1998-05-28 2003-03-11 Oracle Corp. Data replication for front office automation
US6484186B1 (en) 2000-02-15 2002-11-19 Novell, Inc. Method for backing up consistent versions of open files
US6606629B1 (en) * 2000-05-17 2003-08-12 Lsi Logic Corporation Data structures containing sequence and revision number metadata used in mass storage data integrity-assuring technique
US20030070036A1 (en) * 2001-09-28 2003-04-10 Gorobets Sergey Anatolievich Memory system for data storage and retrieval
US20030140210A1 (en) * 2001-12-10 2003-07-24 Richard Testardi Dynamic and variable length extents
US6898688B2 (en) * 2001-12-28 2005-05-24 Storage Technology Corporation Data management appliance
US20040062106A1 (en) * 2002-09-27 2004-04-01 Bhashyam Ramesh System and method for retrieving information from a database
US20040078533A1 (en) 2002-10-18 2004-04-22 Lee Whay Sing Low overhead snapshot in a storage array using a tree-of-slabs metadata

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Sun StorEdge Instant Image Software Architecture Guide", Dec. 2001, 52 pgs.

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100082919A1 (en) * 2008-09-26 2010-04-01 Micron Technology, Inc. Data streaming for solid-state bulk storage devices
US8930645B2 (en) * 2008-09-26 2015-01-06 Micron Technology, Inc. Method and apparatus using linked lists for streaming of data for soild-state bulk storage device
US9575674B2 (en) 2008-09-26 2017-02-21 Micron Technology, Inc. Data streaming for solid-state bulk storage devices
US10007431B2 (en) 2008-09-26 2018-06-26 Micron Technology, Inc. Storage devices configured to generate linked lists
US9043334B2 (en) 2012-12-26 2015-05-26 Industrial Technology Research Institute Method and system for accessing files on a storage system
US10860738B2 (en) 2018-01-30 2020-12-08 Hewlett Packard Enterprise Development Lp Augmented metadata and signatures for objects in object stores
CN111125449A (en) * 2019-12-24 2020-05-08 腾讯科技(深圳)有限公司 Object information storage method, device and storage medium
US20240403370A1 (en) * 2023-06-02 2024-12-05 Dell Products L.P. Support for i/o with signature from initiator
US12204592B2 (en) * 2023-06-02 2025-01-21 Dell Products L.P. Support for i/o with signature from initiator

Also Published As

Publication number Publication date
US20040064463A1 (en) 2004-04-01

Similar Documents

Publication Publication Date Title
US7127465B2 (en) Memory-efficient metadata organization in a storage array
US5454103A (en) Method and apparatus for file storage allocation for secondary storage using large and small file blocks
KR102805147B1 (en) Associative and atomic write-back caching system and method for storage subsystem
US6026475A (en) Method for dynamically remapping a virtual address to a physical address to maintain an even distribution of cache page addresses in a virtual address space
US20230418739A1 (en) Memory system and method for controlling nonvolatile memory
US7085911B2 (en) Resizable cache sensitive hash table
US9256527B2 (en) Logical to physical address mapping in storage systems comprising solid state memory devices
US8095736B2 (en) Methods and systems for dynamic cache partitioning for distributed applications operating on multiprocessor architectures
EP2645259B1 (en) Method, device and system for caching data in multi-node system
US6182089B1 (en) Method, system and computer program product for dynamically allocating large memory pages of different sizes
US7594067B2 (en) Enhanced data access in a storage device
US20110153976A1 (en) Methods and apparatuses to allocate file storage via tree representations of a bitmap
US20140304453A1 (en) Effective Caching for Demand-based Flash Translation Layers in Large-Scale Flash Memory Storage Systems
US6978353B2 (en) Low overhead snapshot in a storage array using a tree-of-slabs metadata
CN114115747A (en) Memory system and control method
US6629111B1 (en) Memory allocation system
US10628318B2 (en) Cache sector usage prediction
WO1995016962A1 (en) Dynamic allocation of page sizes in virtual memory
JPH11102323A (en) Flexible translation storage buffer for virtual address translation
US11126573B1 (en) Systems and methods for managing variable size load units
US5996055A (en) Method for reclaiming physical pages of memory while maintaining an even distribution of cache page addresses within an address space
CN111177019B (en) Memory allocation management method, device, equipment and storage medium
EP1605360B1 (en) Cache coherency maintenance for DMA, task termination and synchronisation operations
US6016529A (en) Memory allocation technique for maintaining an even distribution of cache page addresses within a data structure
US20170092358A1 (en) Content addressable memory with an ordered sequence

Legal Events

Date Code Title Description
AS Assignment

Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RAO, RAGHAVENDRA;LEE, WHAY SING;REEL/FRAME:013349/0925

Effective date: 20020925

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: ORACLE AMERICA, INC., CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037302/0661

Effective date: 20100212

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553)

Year of fee payment: 12

点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载