This invention relates to computer networks and, more particularly, to efficiently maintaining metadata stored among a plurality of solid-state storage devices.
As computer memory storage and data bandwidth increase, so does the amount and complexity of data that businesses daily manage. A distributed storage system may be coupled to client computers interconnected by one or more networks. If any portion of the distributed storage system has poor performance, company operations may be impaired. A distributed storage system therefore maintains high standards for data availability and high-performance functionality.
Various types of metadata are maintained for the distributed storage system. For example, the metadata may consist of at least mapping tables for storage virtualization that allows access to logical storage without end-users identifying physical storage, mapping tables for deduplication operations, and mapping tables for relating virtual sectors at a specific snapshot level to physical locations. A supported address space may be limited by a storage capacity used to maintain the various mapping tables.
Various software applications provide a means of allocating space on mass-storage arrays. At times, operations are started to reduce the supported metadata. For example, new storage space may be allocated for storing one copy of identical records of mappings or a youngest record of multiple corresponding mappings. The distributed storage system utilizes the records stored in the new allocated storage space. The previous storage space may be retained for an appreciable amount of time for possible error recovery or removed once the new storage space starts being used. However, as the size of the metadata significantly increases, the amount of storage space simultaneously used for the old records of metadata and the new records of metadata may approach address space limits.
In view of the above, systems and methods for efficiently maintaining metadata stored among a plurality of solid-state storage devices are desired.
Various embodiments of a computer system and methods for efficiently maintaining metadata stored among a plurality of solid-state storage devices are disclosed.
In various embodiments, a data storage subsystem coupled to a network receives read and write requests on the network from a client computer. The data storage subsystem includes multiple data storage locations on multiple storage devices. The data storage subsystem also includes at least one mapping table. The mapping table includes a plurality of entries, with each of the entries including a tuple with a key. The entry may also include a pointer to a physical location within the multiple storage devices. The mapping table is organized as multiple levels, each level storing multiple mapping table entries.
Responsive to receiving a read request, a write request, or other request for an operation to be performed on the multiple storage devices, a data storage controller searches the multiple levels within a respective mapping table. The data storage controller determines a time to search the multiple levels exceeds a threshold. In response, the data storage controller flattens at least two levels of the multiple levels in an incremental manner. In addition, it may have been determined that the amount of memory used during the flattening operation exceeds a respective threshold. In response, the controller incrementally flattens the selected levels based on entries within a key range. When the selected levels have entries flattened within the key range, those particular entries may be removed from the selected levels. A new key range is chosen, and the process repeats.
These and other embodiments will become apparent upon consideration of the following description and accompanying drawings.
While the invention is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, one having ordinary skill in the art should recognize that the invention might be practiced without these specific details. In some instances, well-known circuits, structures, signals, computer program instruction, and techniques have not been shown in detail to avoid obscuring the present invention.
Referring to
It is noted that in alternative embodiments, the number and type of client computers and servers, switches, networks, data storage arrays, and data storage devices is not limited to those shown in
In the network architecture 100, each of the data storage arrays 120a-120b may be used for the sharing of data among different servers and computers, such as client computer systems 110a-110c. In addition, the data storage arrays 120a-120b may be used for disk mirroring, backup and restore, archival and retrieval of archived data, and data migration from one storage device to another. In an alternate embodiment, one or more client computer systems 110a-110c may be linked to one another through fast local area networks (LANs) in order to form a cluster. Such clients may share a storage resource, such as a cluster shared volume residing within one of data storage arrays 120a-120b.
Each of the data storage arrays 120a-120b includes a storage subsystem 170 for data storage. Storage subsystem 170 may comprise a plurality of storage devices 176a-176m. These storage devices 176a-176m may provide data storage services to client computer systems 110a-110c. Each of the storage devices 176a-176m uses a particular technology and mechanism for performing data storage. The type of technology and mechanism used within each of the storage devices 176a-176m may at least in part be used to determine the algorithms used for controlling and scheduling read and write operations to and from each of the storage devices 176a-176m. For example, the algorithms may locate particular physical locations corresponding to the operations. In addition, the algorithms may perform input/output (I/O) redirection for the operations, removal of duplicate data in the storage subsystem 170, and support one or more mapping tables used for address redirection and deduplication.
The logic used in the above algorithms may be included in one or more of a base operating system (OS) 132, a volume manager 134, within a storage subsystem controller 174, control logic within each of the storage devices 176a-176m, or otherwise. Additionally, the logic, algorithms, and control mechanisms described herein may comprise hardware and/or software.
Each of the storage devices 176a-176m may be configured to receive read and write requests and comprise a plurality of data storage locations, each data storage location being addressable as rows and columns in an array. In one embodiment, the data storage locations within the storage devices 176a-176m may be arranged into logical, redundant storage containers or RAID arrays (redundant arrays of inexpensive/independent disks).
In some embodiments, each of the storage devices 176a-176m may include or be further coupled to storage consisting of solid-state memory to store persistent data. In one embodiment, the included solid-state memory comprises solid-state drive (SSD) technology. A Solid-State Disk (SSD) may also be referred to as a Solid-State Drive.
Storage array efficiency may be improved by creating a storage virtualization layer between user storage and physical locations within storage devices 176a-176m. In one embodiment, a virtual layer of a volume manager is placed in a device-driver stack of an operating system (OS), rather than within storage devices or in a network. A volume manager or a disk array manager is used to support device groups 173a-173m.
In one embodiment, one or more mapping tables may be stored in a data storage medium. Such a storage medium may comprise volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. All such embodiments are contemplated. In one embodiment, mapping tables may be stored in the storage devices 176a-176m. The storage devices 176a-176 may be SSDs utilizing Flash memory. The low read access and latency times for SSDs may allow a small number of dependent read operations to occur while servicing a storage access request from a client computer. The dependent read operations may be used to access one or more indexes, one or more mapping tables, and user data during the servicing of the storage access request.
The information within a mapping table may be compressed. A particular compression algorithm may be chosen to allow identification of individual components, such as a key within a record among multiple records. Therefore, a search for a given key among multiple compressed records may occur. If a match is found, only the matching record may be decompressed. Compressing the tuples within records of a mapping table may further enable fine-grained level mapping.
Network architecture 100 includes client computer systems 110a-110c interconnected through networks 180 and 190 to one another and to data storage arrays 120a-120b. Networks 180 and 190 may include a variety of techniques including wireless connection, direct local area network (LAN) connections, wide area network (WAN) connections such as the Internet, a router, storage area network, Ethernet, and others. Networks 180 and 190 may comprise one or more LANs that may also be wireless. Switch 140 may utilize a protocol associated with both networks 180 and 190. The network 190 may interface with a set of communications protocols used for the Internet 160 such as the Transmission Control Protocol (TCP) and the Internet Protocol (IP), or TCP/IP. Switch 150 may be a TCP/IP switch.
Client computer systems 110a-110c are representative of any number of stationary or mobile computers such as desktop personal computers (PCs), servers, server farms, workstations, laptops, handheld computers, servers, personal digital assistants (PDAs), smart phones, and so forth. Each of the client computer systems 110a-110c may include a hypervisor used to support virtual machines (VMs).
Each of the data storage arrays 120a-120b may be used for the sharing of data among different servers, such as the client computer systems 110a-110c. Each of the data storage arrays 120a-120b includes a storage subsystem 170 for data storage. Storage subsystem 170 may comprise a plurality of storage devices 176a-176m. Each of these storage devices 176a-176m may be an SSD. A controller 174 may comprise logic for handling received read/write requests. A random-access memory (RAM) 172 may be used to batch operations, such as received write requests. In various embodiments, when batching write operations (or other operations) non-volatile storage (e.g., NVRAM) may be used.
The base OS 132, the volume manager 134 (or disk array manager 134), any OS drivers (not shown) and other software stored in memory medium 130 may provide functionality providing access to files and the management of these functionalities. The base OS 132 and the OS drivers may comprise program instructions stored on the memory medium 130 and executable by processor 122 to perform one or more memory access operations in storage subsystem 170 that correspond to received requests. Each of the data storage arrays 120a-120b may use a network interface 124 to connect to network 180. Similar to client computer systems 110a-110c, in one embodiment, the functionality of network interface 124 may be included on a network adapter card.
In addition to the above, each of the storage controllers 174 within the data storage arrays 120a-120b may support storage array functions such as snapshots, replication and high availability. In addition, each of the storage controllers 174 may support a virtual machine environment that comprises a plurality of volumes with each volume including a plurality of snapshots. In one example, a storage controller 174 may support hundreds of thousands of volumes, wherein each volume includes thousands of snapshots. In one embodiment, a volume may be mapped in fixed-size sectors, such as a 4-kilobyte (KB) page within storage devices 176a-176m. In another embodiment, a volume may be mapped in variable-size sectors such as for write requests. A volume ID, a snapshot ID, and a sector number may be used to identify a given volume.
An address translation table may comprise a plurality of entries, wherein each entry holds a virtual-to-physical mapping for a corresponding data component. This mapping table may be used to map logical read/write requests from each of the client computer systems 110a-110c to physical locations in storage devices 176a-176m. A “physical” pointer value may be read from the mapping table during a lookup operation corresponding to a received read/write request. This physical pointer value may then be used to locate a physical location within the storage devices 176a-176m. It is noted the physical pointer value may be used to access another mapping table within a given storage device of the storage devices 176a-176m. Consequently, one or more levels of indirection may exist between the physical pointer value and a target storage location.
Turning now to
The information stored in the records, pages and levels shown in
Generally speaking, each mapping table comprises a set of rows and columns. A single record may be stored in a mapping table as a row. A record may also be referred to as an entry. In one embodiment, a record stores at least one tuple including a key. Tuples may (or may not) also include data fields including data such as a pointer used to identify or locate data components stored in storage subsystem 170. It is noted that in various embodiments, the storage subsystem may include storage devices (e.g., SSDs), which have internal mapping mechanisms. In such embodiments, the pointer in the tuple may not be an actual physical address per se. Rather, the pointer may be a logical address, which the storage device maps to a physical location within the device. Over time, this internal mapping between logical address and physical location may change. In other embodiments, records in the mapping table may only contain key fields with no additional associated data fields. Attributes associated with a data component corresponding to a given record may be stored in columns, or fields, in the table. Status information, such as a valid indicator, a data age, a data size, and so forth, may be stored in fields, such as Field0 to FieldN shown in
A key is an entity in a mapping table that may distinguish one row of data from another row. Each row may also be referred to as an entry or a record. A key may be a single column, or it may consist of a group of columns used to identify a record. In some embodiments, a key may correspond to a range of values rather than to a single value. A key corresponding to a range may be represented as a start and end of a range, or as a start and length, or in other ways. The ranges corresponding to keys may overlap with other keys, either ranges or individual values. In one example, an address translation mapping table may utilize a key comprising a volume identifier (ID), a logical or virtual address, a snapshot ID, a sector number, and so forth. A given received read/write storage access request may identify a particular volume, sector and length. A sector may be a logical block of data stored in a volume. Sectors may have different sizes on different volumes. The address translation mapping table may map a volume in sector-size units.
A volume identifier (ID) may be used to access a volume table or a snapshot table that conveys and ID (e.g., a corresponding current snapshot ID). This information along with the received sector number may be used to access the address translation mapping table. Therefore, in such an embodiment, the key value for accessing the address translation mapping table is the combination of the volume ID, snapshot ID, and the received sector number. In one embodiment, the records within the address translation mapping table are sorted by volume ID, followed by the sector number and then by the snapshot ID. This ordering may group together different versions of data components in different snapshots. Therefore, during a lookup for a storage access read request, a corresponding data component may be found with fewer read operations to the storage devices 176a-176m.
The address translation mapping table may convey a physical pointer value that indicates a location within the data storage subsystem 170 storing a data component corresponding to the received data storage access request. The key value may be compared to one or more key values stored in the mapping table. In the illustrated example, simpler key values, such as “0”, “2”, “12” and so forth, are shown for ease of illustration. The physical pointer value may be stored in one or more of the fields in a corresponding record.
The physical pointer value may include a segment identifier (ID) and a physical address identifying the location of storage. A segment may be a basic unit of allocation in each of the storage devices 176a-176m. A segment may have a redundant array of independent device (RAID) level and a data type. During allocation, a segment may have one or more of the storage devices 176a-176m selected for corresponding storage. The data storage access request may correspond to multiple sectors, which may result in multiple parallel lookups. A write request may be placed in an NVRAM buffer, such as RAM 172, and a write completion acknowledgment may be sent to a corresponding client computer of the client computers 110a-110c. At a later time, an asynchronous process may flush the buffered write requests to the storage devices 176a-176m.
A mapping table may comprise one or more levels as shown in
In one embodiment, multiple levels within a mapping table are sorted by time. For example, in
By creating a new highest level for an insertion of new records, the mapping table is updated by appending the new records. In one embodiment, a single level is created as a new highest level and each of the new records is inserted into the single level. In another embodiment, the new records may be searched for duplicate keys prior to insertion into the mapping table. When a given record storing a duplicate key is found, each of the records buffered ahead of the given record may be inserted into the single level. In some embodiments, the new records may be buffered in a manner to preserve memory ordering, such as in-order completion of requests. Subsequently, another single level may be created and the remainder of the new records may be inserted into this other level unless another record storing a duplicate key is found. If such a record is found, then the steps may be repeated. When a new record is received and a duplicate is found, the duplicate is not edited or overwritten in-place by the insertion of the new records. Rather, updates are performed by appending new records as noted above.
With no edits in-place for the records stored in the mapping table, newer records placed in higher levels may override records storing a same key value located in the lower levels. For example, when the mapping table is accessed by a given key value, one or more levels may be found to store a record holding a key value matching the given key value. In such a case, the highest level of the one or more levels may be chosen to provide the information stored in its corresponding record as a result of the access.
In one embodiment, entries within a given page may be sorted by key. For example, the entries may be sorted in ascending order according to a key included in the entry. Additionally, in various embodiments, the pages within a level may be sorted according to any desired sort order. In various embodiments, the pages within a level may also be sorted (e.g., according to key values or otherwise). In the example of
Turning now to
In various embodiments, when the time to search the multiple levels in the mapping table exceeds a threshold, one or more operations may be performed to reduce the number of levels. In one embodiment, the number of levels that must be searched may be reduced by “flattening” one or more existing levels into a single new level. For example, two or more contiguous levels may be chosen for a flattening operation. In such an embodiment, records storing a unique key value within the two or more levels are stored in the new level. Additionally, if two or more records are identified that store a duplicate key value, then only the youngest such record is stored in the new level. The youngest record in such an embodiment corresponds to the latest or most up to date version of the records. In this manner, all records of interest within the two or more levels (during a typical search) will exist in this single new level.
In the above described embodiment, the new single level returns a same result for a search for a given key value as a result provided by the two or more levels it replaces. Since the input and output of data to/from the new single level does not change compared to the two or more levels it replaces, the flattening operation is not synchronized with update operations to the mapping table. No synchronization lock may be used. However, in a node-based cluster, each node may verify it is ready to utilize the new single level and no longer use the two or more levels it replaces prior to the new level becomes the replacement. In one embodiment, the two or more replaced levels may be kept in storage for error recovery purposes.
In the illustrated example in
The new Level “New G” includes the duplicate key values found in Level “G” and Level “G+1”. In addition, the new Level “New G” includes a pointer value corresponding to the youngest (or younger in this case) record of the records storing the duplicate key value. For example, each of Level “G” and Level “G+1” includes a record storing the key value 4. The younger record is in Level “G” and this record also stores the pointer value 512. Accordingly, the Level “New G” includes a record storing the key value 4 and also the pointer value 512, rather than the pointer value 656 found in the older Level “G+1”.
Additionally, the new Level “New G” includes records with unique key values found between Level “G” and Level “G+1”. For example, the Level “New G” includes records with the key and pointer pair of 6 and 246 found in Level “G” and the key and pointer pair of 2 and 398 found in Level “G+1”. As shown, each of the partitions within the levels is sorted by key value.
Referring now to
In the earlier example in
In response to determining an amount of memory usage for the selected levels for flattening exceeds a threshold, an incremental flattening operation may be performed. In the example shown, a first key range of 0 to 10 has been selected. A flattening operation is performed within the first key range. The new Level “New G” includes the duplicate key values found in Level “G” and Level “G+1” within the first key range of keys 0 to 10, such as keys 4 and 9.
In addition, the new Level “New G” includes a pointer value corresponding to the youngest (or younger in this case) record of the records storing the duplicate key value. Accordingly, the Level “New G” includes a record storing the key value 4 and also the pointer value 512, rather than the pointer value 656 found in the older Level “G+1”. The Level “New G” also includes a record storing the key value 9 and the pointer value 814, rather than the pointer value 388 found in the older Level “G+1”.
Additionally, the new Level “New G” includes records with unique key values found between Level “G” and Level “G+1” and within the first key range of 0 to 10. For example, the Level “New G” includes records with the key and pointer pair of 6 and 246 found in Level “G” and the key and pointer pairs of 2 and 398 along with 7 and 423 found in Level “G+1”. As shown, each of the partitions within the levels is sorted by key value. The Size New G is about one third the size used in the previous example in
Turning now to
Referring now to
The Level “New G” includes a record storing the key value 12 and also the pointer value 921, rather than the pointer value 543 found in the older Level “G+1”. The Level “New G” also includes a record storing the key value 17 and the pointer value 436, rather than the pointer value 614 found in the older Level “G+1”. The new Level “New G” includes records with unique key values found between Level “G” and Level “G+1” and within the second key range of 11 to 20. For example, the Level “New G” includes records with the key and pointer pair of 11 and 598, 13 and 221, and 20 and 902 found in Level “G+1”. Although the Size New G increases, both sizes of Level “G” and Level “G+1” remain reduced. Therefore, the amount of memory being used for the incremental flattening may be significantly reduced.
Referring now to
Turning now to
Storage space is allocated for a mapping table and corresponding indexes. In block 802, the mapping table and indexes are accessed during operations in a storage subsystem. The mapping table and indexes are updated over time. New levels are added to the mapping table over time. The search time for a key within the levels may exceed a threshold. Alternatively, a number of levels built in the mapping table may exceed a threshold. An amount of memory used to store the levels of the mapping table may exceed a threshold. Cost of searching the levels within the mapping table may also include time to perform a corresponding operation, an occupation of one or more buses, storage space used during a corresponding operation, and so forth. In addition, a count of a number of records within each level may be used to estimate when an incremental flattening operation is performed. If a condition for incrementally flattening levels is satisfied (conditional block 804), then in block 806, two or more levels are selected for incremental flattening. Although the lowest levels, or the oldest levels, may be the best candidates for flattening, a younger group may also be selected.
For incremental flattening, in block 808, a key range representing less than a complete level is identified. In various embodiments, a level may include a start key value and an end key value indicating a range of key values represented within the given level. In order to process or flatten less than an entire level, a subset of a range of key values (or “subrange”) corresponding to a given level may be identified. Entries in the levels corresponding to keys within the subset are then processed during the incremental flattening operation. Selection of a particular subrange may be determined in a variety of ways. For example, the number of keys within a key range may be used to determine a subset of entries to process. For example, if there are a relatively large number of entries within a given key range, then the subrange that is selected may be smaller than if the number of entries within the given key range is relatively small (i.e., a wider range is used for sparsely populated ranges and a narrower range for more densely populated ranges). In this manner, the number of entries processed may controlled. In some embodiments, the number of keys within a given key range may identified by a value stored in a configuration or status register, as part of an entry in a level, or otherwise. In other embodiments, the number of keys in the key range may be determined or estimated from the sizes of the selected levels. Numerous such embodiments are possible and are contemplated.
The key range may be a particular fraction of the total number of records stored in the selected levels, wherein the fraction is stored in a configuration or status register. Alternatively, the key range may be computed based on ranges of the number of records in the selected levels. In some embodiments, the size of the key range is the same during each iteration of the incremental flattening. In other embodiments, the sizes of the key ranges may differ in one or more iterations from other key range sizes used in other iterations.
If the incremental flattening hasn't finished and there are key ranges to process (conditional block 810), then in block 812, a next key range to process is selected. The start key value, the end key value, and the size of the key range to process may use one of the previously described methods. If the current iteration of the incremental flattening hasn't finished and there are keys to process in the key range (conditional block 814), then in block 816, a next key in the current key range is selected to process.
If the next key in the key range is unique among the selected levels (conditional block 818), then in block 820, the mapping associated with the given key (next key) is inserted in a subset of the new level. If the next key in the key range is not unique among the selected levels (conditional block 818), then in block 822, the youngest mapping for the given key (next key) is selected. In block 820, the selected youngest mapping associated with the given key (next key) is inserted in the subset of the new level. Following, control flow of method 800 moves to conditional block 814.
If the current iteration of the incremental flattening has finished and there are no more keys to process in the current key range (conditional block 814), then in block 824, the mappings in the current key range in the selected levels may be removed. Memory usage during the incremental flattening may be reduced by removing these records from the selected levels. For each key range, a new range is produced in a new single level. In the earlier example, the new single Level “New G” includes the youngest records and the unique records among the Level “G” and the Level “G+1” one key range at a time.
It is noted that the above-described embodiments may comprise software. In such an embodiment, the program instructions that implement the methods and/or mechanisms may be conveyed or stored on a computer readable medium. Numerous types of media which are configured to store program instructions are available and include hard disks, floppy disks, CD-ROM, DVD, flash memory, Programmable ROMs (PROM), random access memory (RAM), and various other forms of volatile or non-volatile storage.
In various embodiments, one or more portions of the methods and mechanisms described herein may form part of a cloud-computing environment. In such embodiments, resources may be provided over the Internet as services according to one or more various models. Such models may include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In IaaS, computer infrastructure is delivered as a service. In such a case, the computing equipment is generally owned and operated by the service provider. In the PaaS model, software tools and underlying equipment used by developers to develop software solutions may be provided as a service and hosted by the service provider. SaaS typically includes a service provider licensing software as a service on demand. The service provider may host the software, or may deploy the software to a customer for a given period of time. Numerous combinations of the above models are possible and are contemplated.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
This application is a Continuation Application of and claims priority from U.S. patent application Ser. No. 15/638,912, filed Jun. 30, 2017, which claims priority from U.S. Pat. No. 9,727,485, issued Aug. 8, 2017.
Number | Name | Date | Kind |
---|---|---|---|
5208813 | Stallmo | May 1993 | A |
5403639 | Belsan | Apr 1995 | A |
5940838 | Schmuck et al. | Aug 1999 | A |
6263350 | Wollrath et al. | Jul 2001 | B1 |
6412045 | DeKoning et al. | Jun 2002 | B1 |
6718448 | Ofer | Apr 2004 | B1 |
6757769 | Ofer | Jun 2004 | B1 |
6799283 | Tamai et al. | Sep 2004 | B1 |
6834298 | Singer et al. | Dec 2004 | B1 |
6850938 | Sadjadi | Feb 2005 | B1 |
6915434 | Kuroda | Jul 2005 | B1 |
6973549 | Testardi | Dec 2005 | B1 |
7028216 | Aizawa et al. | Apr 2006 | B2 |
7028218 | Schwarm et al. | Apr 2006 | B2 |
7039827 | Meyer et al. | May 2006 | B2 |
7216164 | Whitmore et al. | May 2007 | B1 |
7783682 | Patterson | Aug 2010 | B1 |
7873619 | Faibish et al. | Jan 2011 | B1 |
7913300 | Flank et al. | Mar 2011 | B1 |
7933936 | Aggarwal et al. | Apr 2011 | B2 |
7979613 | Zohar et al. | Jul 2011 | B2 |
8086652 | Bisson et al. | Dec 2011 | B1 |
8117464 | Kogelnik | Feb 2012 | B1 |
8200887 | Bennett | Jun 2012 | B2 |
8205065 | Matze | Jun 2012 | B2 |
8352540 | Anglin et al. | Jan 2013 | B2 |
8527544 | Colgrove et al. | Sep 2013 | B1 |
8560747 | Tan et al. | Oct 2013 | B1 |
8621241 | Stephenson | Dec 2013 | B1 |
8700875 | Barron et al. | Apr 2014 | B1 |
8751463 | Chamness | Jun 2014 | B1 |
8806160 | Colgrove et al. | Aug 2014 | B2 |
8874850 | Goodson et al. | Oct 2014 | B1 |
8959305 | Lecrone et al. | Feb 2015 | B1 |
9081713 | Bennett | Jul 2015 | B1 |
9189334 | Bennett | Nov 2015 | B2 |
9311182 | Bennett | Apr 2016 | B2 |
9423967 | Colgrove et al. | Aug 2016 | B2 |
9436396 | Colgrove et al. | Sep 2016 | B2 |
9436720 | Colgrove et al. | Sep 2016 | B2 |
9454476 | Colgrove et al. | Sep 2016 | B2 |
9454477 | Colgrove et al. | Sep 2016 | B2 |
9513820 | Shalev | Dec 2016 | B1 |
9516016 | Colgrove et al. | Dec 2016 | B2 |
9552248 | Miller et al. | Jan 2017 | B2 |
9632870 | Bennett | Apr 2017 | B2 |
20020038436 | Suzuki | Mar 2002 | A1 |
20020087544 | Selkirk et al. | Jul 2002 | A1 |
20020178335 | Selkirk et al. | Nov 2002 | A1 |
20030140209 | Testardi | Jul 2003 | A1 |
20040049572 | Yamamoto et al. | Mar 2004 | A1 |
20050066095 | Mullick et al. | Mar 2005 | A1 |
20050216535 | Saika et al. | Sep 2005 | A1 |
20050223154 | Uemura | Oct 2005 | A1 |
20060074940 | Craft et al. | Apr 2006 | A1 |
20060136365 | Kedem et al. | Jun 2006 | A1 |
20060155946 | Ji | Jul 2006 | A1 |
20070067585 | Ueda et al. | Mar 2007 | A1 |
20070162954 | Pela | Jul 2007 | A1 |
20070171562 | Maejima et al. | Jul 2007 | A1 |
20070174673 | Kawaguchi et al. | Jul 2007 | A1 |
20070220313 | Katsuragi et al. | Sep 2007 | A1 |
20070245090 | King et al. | Oct 2007 | A1 |
20070266179 | Chavan et al. | Nov 2007 | A1 |
20080059699 | Kubo et al. | Mar 2008 | A1 |
20080065852 | Moore et al. | Mar 2008 | A1 |
20080134174 | Sheu et al. | Jun 2008 | A1 |
20080155191 | Anderson et al. | Jun 2008 | A1 |
20080178040 | Kobayashi | Jul 2008 | A1 |
20080209096 | Lin et al. | Aug 2008 | A1 |
20080244205 | Amano et al. | Oct 2008 | A1 |
20080275928 | Shuster | Nov 2008 | A1 |
20080285083 | Aonuma | Nov 2008 | A1 |
20080307270 | Li | Dec 2008 | A1 |
20090006587 | Richter | Jan 2009 | A1 |
20090037662 | La Frese et al. | Feb 2009 | A1 |
20090204858 | Kawaba | Aug 2009 | A1 |
20090228648 | Wack | Sep 2009 | A1 |
20090300084 | Whitehouse | Dec 2009 | A1 |
20100057673 | Savov | Mar 2010 | A1 |
20100058026 | Heil et al. | Mar 2010 | A1 |
20100067706 | Anan et al. | Mar 2010 | A1 |
20100077205 | Ekstrom et al. | Mar 2010 | A1 |
20100082879 | McKean et al. | Apr 2010 | A1 |
20100106905 | Kurashige et al. | Apr 2010 | A1 |
20100153620 | McKean et al. | Jun 2010 | A1 |
20100153641 | Jagadish et al. | Jun 2010 | A1 |
20100191897 | Zhang et al. | Jul 2010 | A1 |
20100250802 | Waugh et al. | Sep 2010 | A1 |
20100250882 | Hutchison et al. | Sep 2010 | A1 |
20100281225 | Chen et al. | Nov 2010 | A1 |
20100287327 | Li et al. | Nov 2010 | A1 |
20110072300 | Rousseau | Mar 2011 | A1 |
20110145598 | Smith et al. | Jun 2011 | A1 |
20110161559 | Yurzola et al. | Jun 2011 | A1 |
20110167221 | Pangal et al. | Jul 2011 | A1 |
20110238634 | Kobara | Sep 2011 | A1 |
20120023375 | Dutta et al. | Jan 2012 | A1 |
20120036309 | Dillow et al. | Feb 2012 | A1 |
20120117029 | Gold | May 2012 | A1 |
20120198175 | Atkisson | Aug 2012 | A1 |
20120330954 | Sivasubramanian et al. | Dec 2012 | A1 |
20130042052 | Colgrove et al. | Feb 2013 | A1 |
20130046949 | Colgrove | Feb 2013 | A1 |
20130046995 | Movshovitz | Feb 2013 | A1 |
20130047029 | Ikeuchi et al. | Feb 2013 | A1 |
20130091102 | Nayak | Apr 2013 | A1 |
20130205110 | Kettner | Aug 2013 | A1 |
20130227236 | Flynn et al. | Aug 2013 | A1 |
20130275391 | Batwara et al. | Oct 2013 | A1 |
20130275656 | Talagala et al. | Oct 2013 | A1 |
20130283058 | Fiske et al. | Oct 2013 | A1 |
20130290648 | Shao et al. | Oct 2013 | A1 |
20130318314 | Markus et al. | Nov 2013 | A1 |
20130339303 | Potter et al. | Dec 2013 | A1 |
20140052946 | Kimmel | Feb 2014 | A1 |
20140068791 | Resch | Mar 2014 | A1 |
20140089730 | Watanabe et al. | Mar 2014 | A1 |
20140101361 | Gschwind | Apr 2014 | A1 |
20140143517 | Jin et al. | May 2014 | A1 |
20140172929 | Sedayao et al. | Jun 2014 | A1 |
20140201150 | Kumarasamy et al. | Jul 2014 | A1 |
20140215129 | Kuzmin et al. | Jul 2014 | A1 |
20140229131 | Cohen et al. | Aug 2014 | A1 |
20140229452 | Serita et al. | Aug 2014 | A1 |
20140281308 | Lango et al. | Sep 2014 | A1 |
20140325115 | Ramsundar et al. | Oct 2014 | A1 |
20150234709 | Koarashi | Aug 2015 | A1 |
20150244775 | Vibhor et al. | Aug 2015 | A1 |
20150278534 | Thiyagarajan et al. | Oct 2015 | A1 |
20160019114 | Han et al. | Jan 2016 | A1 |
20160098191 | Golden et al. | Apr 2016 | A1 |
20160098199 | Golden et al. | Apr 2016 | A1 |
Number | Date | Country |
---|---|---|
103370685 | Oct 2013 | CN |
103370686 | Oct 2013 | CN |
104025010 | Nov 2016 | CN |
3066610 | Sep 2016 | EP |
3082047 | Oct 2016 | EP |
3120235 | Jan 2017 | EP |
2007-087036 | Apr 2007 | JP |
2007-094472 | Apr 2007 | JP |
2008-250667 | Oct 2008 | JP |
2010-211681 | Sep 2010 | JP |
WO-1995002349 | Jan 1995 | WO |
WO-1999013403 | Mar 1999 | WO |
WO-2008102347 | Aug 2008 | WO |
WO-2010071655 | Jun 2010 | WO |
Entry |
---|
Posey, Brien, 10 things you should know about long term data archiving, TechRepublic, Jul. 15, 2010 https://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-long-term-data-archiving/ (Year: 2010). |
Microsoft Corporation, “GCSettings.IsServerGC Property”, Retrieved Oct. 27, 2013 via the WayBack Machine, 3 pages. |
Microsoft Corporation, “Fundamentals of Garbage Collection”, Retrieved Aug. 30, 2013 via the WayBack Machine, 11 pages. |
Number | Date | Country | |
---|---|---|---|
Parent | 15638912 | Jun 2017 | US |
Child | 15966036 | US | |
Parent | 14552172 | Nov 2014 | US |
Child | 15638912 | US |