A proxy may be connected between different computing devices and operates on behalf of one or more of the computing devices. The proxy monitors messages exchanged between the computing devices and operates according to a current system state associated with the messages exchanged between the computing devices. Events may prevent the proxy from monitoring the messages exchanged between the computing devices and cause the proxy to lose track of the current state that exists between the computing devices. The proxy may delay operations or operate sub-optimally until a current state between the computing devices is re-determined.
The initiators 100 and targets 300 can be directly connected, or connected to each other through a network or fabric. In some embodiments, the initiators 100 are servers, server applications, routers, switches, client computers, personal computers, Personal Digital Assistants (PDA), smart phones, or any other wired or wireless computing device that needs to access the data in targets 300.
In one embodiment, the initiators 100 may be stand-alone appliances, devices, or blades, and the targets 300 are stand-alone storage arrays. In some embodiments, the initiators 100, storage proxy 200, and targets 300 are each coupled to each other via wired or wireless Internet connections 12. In other embodiments, the initiators 100 may be a processor or software applications in a personal computer or server that accesses one or more targets 300 over an internal or external data bus. The targets 300 in this embodiment could be located in the personal computer or server 100, or could also be a stand-alone device coupled to the computer/initiators 100 via a computer bus or packet switched network connection.
The storage proxy 200 could be any hardware and/or software located in a storage appliance, wireless or wired router, gateway, firewall, switch, or any other computer processing system. The storage proxy 200 provides an abstraction of physical disks 500 in targets 300 as virtual disks 400. In one embodiment, the physical disks 500 and the virtual disks 400 may be identical in size and configuration. In other embodiments the virtual disks 400 could consist of stripes of data or volumes of data that extend across multiple different physical disks 500. In another embodiment, virtual disks 400 are simply presentations of existing virtual disks within targets 300 such that initiators 100 accessing said virtual disks are served data from either virtual disks 400 or disks controlled by targets 300. In such a configuration, data served by virtual disks 400 within storage proxy 200 would be expected to have lower latency or higher throughput, thereby demonstrating the rationale for deploying storage proxy 100.
Different communication protocols can be used over connections 12 between initiators 100 and targets 300. Typical protocols include Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Advanced Technology Attachment (ATA) and encapsulated protocols such as Fibre Channel over Ethernet (FCoE), Internet Small Computer System Interface (ISCSI), Fibre Channel over Internet Protocol (FCIP), ATA over Ethernet (AoE) and others. In one embodiment, the communication protocol is a routed protocol such that any number of intermediate routing or switching agents may be used to abstract connection 12.
The initiators 100 conduct different storage operations with the physical disks 500 in targets 300 though the storage proxy 200. The storage operations may include write operations and read operations that have associated storage addresses. These interactions with storage proxy 200 and other components of storage proxy 200 may be normalized to block-level operations such as “reads” and “writes” of an arbitrary number of blocks.
Storage proxy 200 contains a cache resource 16 used for accelerating accesses to targets 300. The cache resource 16 includes an array of cache lines 207 that include both cache memory that stores data, and registers and logic that maintain a state for the different cache lines 207. The cache memory associated with cache lines 207 could be implemented with any memory device that provides relatively faster data access than the targets 300. In one embodiment, the memory in cache resource 16 could be any combination of Dynamic Random Access Memory (DRAM) and/or Flash memory. However, other types of relatively faster memory could also be used.
A prefetch controller 20 includes any combination of software and/or hardware within storage proxy 200 that controls cache resource 16. During a prefetch operation, prefetch controller 18 performs one or more reads to targets 300 beyond the read requested by initiators 100 and stores the additional data in cache resource 16. If subsequent read requests from initiators 100 request data in cache resource 16, storage proxy 200 returns the data directly from cache resource 16 instead of from targets 300. Such a direct return is referred to as a “cache hit” and reduces the read time for applications on initiators 100 accessing targets 300. For example, a memory access to targets 300 can take several milliseconds while a memory access to cache resource 16 may be in the order of microseconds. The logic and algorithms determining the length and address of such additional reads exists within prefetch controller 18 and may be influenced or programmed by processor 22.
Prefetch controller 18 can operate in both a monitoring mode and an active mode. When operating in the monitoring mode, the prefetch controller 18 monitors and records read and write operations from initiators 100 to targets 300. The prefetch controller 18 then uses the monitored information when performing subsequent tiering or caching operations.
High Availability Storage Systems
The storage system in
The initiators 100 may normally send storage access requests over connections 12. The storage proxy 200 intercepts the storage access requests. If the data associated with the storage access requests is located in cache resource 16, the storage proxy 200 sends the identified data in the cache resource 16 to the initiators 100. If the data associated with a particular storage access request is not located in the cache resource 16, the storage proxy 200 forwards the storage access request to the targets 300. The targets 300 access the data from physical disks 500 and forwards the data back to the storage proxy 300 over connection 12. The storage proxy 200 then forwards the data received back from the targets 300 to the initiators 100.
The initiators 100 typically send storage access requests over connections 12. If the storage proxy 200 fails for any reason, the initiators 100 may start sending the storage access requests over direct connection 14. When the storage proxy 200 comes back on line, the initiators 100 start sending the storage access requests back over connections 12. The storage proxy 200 then resumes the prefetch and caching operations described above.
However, the data in cache resource 16 became inconsistent with the data in targets 500 when the initiators 100 switched over to direct connection 14. For example, storage proxy 200 no longer has knowledge of what write requests were sent by the initiators 100 over by-pass connection 14. The address for the data written into physical disks 500 may also correspond with a cache line 207 in cache resource 16. However, the data in cache line 207 now contains an out of date version of the data subsequently written into physical disks 500. Therefore, the data in cache line 207 is inconsistent with the data having the same corresponding physical address in physical disks 500.
To prevent data inconsistencies between the data in cache resource 16 and data in targets 300, all of the data in the cache resource 16 is invalidated whenever the initiators 100 start sending storage access requests over direct connection 14. The cache resource 16 is then repopulated during the normal course of prefetch and other operations performed by the storage proxy 200 while monitoring the storage access requests from initiators 100. However, it may take several hours or several days for the storage proxy 200 to reload the cache resource 16 with data in a state equivalent to what was maintained prior to the storage proxy 200 going offline. Although cache resource 16 must invalidate stored data when direct connection 14 is in use, it need not invalidate the address within targets 300 of said data stored within cache resource 16.
The cache resource 16 may have terabytes of storage space and the data currently loaded into the cache lines 207 may be based on read or write operations that were performed several days ago. For example, it may take several days for the storage proxy 200 to observe memory access patterns that result in the prefetch controller 20 loading a particular set of data into cache resource 16. The storage proxy 200 does not operate efficiency when the cache resource 16 contains large amounts of invalid or irrelevant data. Specifically, the cache resource 16 is less likely to contain the data requested by initiators 100 and is therefore more likely has to forward more read requests to the slower physical disks 500 in targets 300.
Improved Cache Loading
As explained above, a connection path change may be responsive to the storage proxy 200 failing or going offline condition. The path switch may also be identified when a corresponding path switch message is sent to the storage proxy 200. For example, a storage fabric reconfiguration message may indicate a path switch. Any other storage fabric messaging that indicates a change in the communication path can also be used. Responsive to the switch to direct path 14, the storage proxy 200 in operation 256 invalidates all of the cache lines in cache resource 16 in
Invalidation of the cache lines 207 can also be triggered by other events that do not necessarily involve the initiators 100 switching to direct connection path 14 for sending storage access requests to targets 300. For example, the data in cache resource 16 may become inconsistent when a snapshot is taken of the data in targets 300. This snapshot condition and how it is detected by the storage proxy 200 is described in copending U.S. patent application Ser. No. 12/794,057 which is herein incorporated by reference in its entirety.
The storage proxy 200 may invalidate the data in the cache resource 16 by setting invalid flags in all of the cache lines 207. In one embodiment, the storage proxy 200 may switch any of the cache lines 207 that are currently valid into a previously valid state. Any cache line 207 that were previously invalid remains in the invalid state. The valid, invalid, and previously valid flags are contained in the state information 272 shown below in
In operation 258 the storage proxy 200 goes into a standby mode until the initiator 100 switches back to sending the storage access requests over the connection path 12 in operation 260. Again, the storage proxy 200 can determine the switch back to path 12 in
The storage proxy 200 in operation 262 uploads data from targets 300 back into the cache resource 16 using an optimized upload list 24 that is shown in
The data identified in the upload list 24 is uploaded from physical disks 500 into cache resource 16. The upload operation is optimized to further reduce the amount of time required to place the cache resource 16 back into a state close to what existed prior to being invalidated in operation 256. As a result, the storage proxy 200 can start operating at a higher efficiently in less time. The optimized upload patterns are described in more detail below.
A last timestamp value 276 indicates the last time the data in cache line 207 was read. A physical storage address 278 is associated with the location in physical disks 500 where the data 280 in cache line 280 is also located. Contiguous cache lines 207 may contain contiguous blocks of data from targets 300. Therefore, a physical storage address 278 may not be needed for each individual cache line 207.
The processor 22 may or may not need the state information 272 to derive the upload list 24 in
A timestamp less than the predetermined limit indicates the associated cache line 207 has been recently read and is more likely to provide cache hits if reloaded back into the cache resource 16. A read count value 274 above a predetermined limit indicates the associated cache line 207 has been frequently read over a prior time period and is also likely to provide cache hits if uploaded back into cache resource 16. If the last timestamp value 276 is below the predetermined limit in operation 352 and the read count value 274 is above the predetermined limit in operation 354, the processor in operation 356 determines if an upload list 24 currently exists.
The processor 22 creates an upload list 24 in operation 358 if one does not exist in operation 356. The upload list 24 identifies the address range for the data in the currently analyzed cache line 207. For example, the cache line 207 may be 4 thousand bytes (KB) wide and may have a physical storage address 278 in
The processor in operation 360 extends the upload list 24 to include the address range of the currently analyzed cache line 207, if one already exists in operation 356. For example, a next qualifying cache line 207 after the cache line at address 5000 may start at address 9000. The cache line at address 9000 also has a last timestamp value 276 below the time limit in operation 352 and has a read count value 274 above the count limit in operation 354. In operation 360 the processor extends the address range in upload list 24 to start at address 5000 and end at address 12,000.
The processor in operation 362 determines if the address range identified in the upload list 24 is above a predetermined size. For example, the predetermined size could be set at 250 KBs, 500 KBs, 1 million bytes (MBs), or any other configurable value. If the data size associated with the address range in the upload list 24 is not over the size limit, the processor analyzes the next cache line 207 in the cache resource 16 in operation 366. If data size associated with the address range in the upload list 24 is above the size limit in operation 362, the processor 22 uploads the data at the identified address range within targets 300 back into the cache resource 16. The processor 22 flags the uploaded data in the cache lines 207 as valid in state information 272 and moves on to the next cache line 207 in operation 366.
A large address range may exist between two cache lines that qualify for adding to the upload list 24. For example, a first cache line associated with address 0 may be added to the upload list 24 and the next cache line that qualifies for the upload list 24 may be associated with address 40,000. The address range in the upload list 24 would then start at address 0 and end at address 44,000. This could result in the processor 22 uploading nearly 176 MBs of data into the cache resource 16 when only two of the 4 KB cache lines 207 qualified for uploading.
The processor 22 can be programmed with a second upload limit in operation 364 that resets the upload list 24 after a particular amount of data is identified. For example, the upload limit may be 250 KBs. The processor 22 would conduct a first 250 KB upload operation starting at address 0 that contains the data for the first qualifying cache line 207 and conduct a second 250 KB upload operation starting at address 40,000 that contains the data for the second qualifying 4 KB cache line 207.
In another embodiment, the process may abort uploading a particular cache line 207 if the space between that cache line and a next upload qualifying cache line 207 is too large. Using the same example, the first upload qualifying cache line 207 starts at address 0 and the next upload qualifying cache line 207 starts at address 40,000. The processor 22 in operation 358 starts an upload list 24 that starts at address 0. The processor in operation 360 determines that the address gap between the first upload qualifying cache line 207 and the next upload qualifying cache line 207 is greater than a predetermined threshold. As mentioned above, in this example, the address gap is nearly 166 MBs. The processor 22 in operation 360 resets the starting address of the upload list 24 to the starting address 40,000 of the second cache line. This prevents the first cache line at address 0 from being uploaded. However, not uploading the first qualifying cache line is less likely to affect the performance of the storage proxy 200 than uploading 176 MBs of data into the cache resource 16 that might produce a relatively few number of cache hits. The decision to not upload a cache line may be driven by configuration within processor 22.
Loading Data Clusters
The prefetch controller 20 identifies the address range and other state information for a cluster 208. The prefetch controller 20 then monitors the subsequent read operations from initiators 100. If the address of a read request comes within one of the address range identified in one of the clusters 208, the prefetch controller 20 may load the entire cluster of contiguous data blocks from physical disks 500 into cache resource 16. Generating and using the cluster map 18 is described in more detail in U.S. patent application Ser. Nos. 12/814,438 filed on Jun. 12, 2010; Ser. No. 12/605,119 filed on Oct. 23, 2009; and Ser. No. 12/605,160 filed Oct. 23, 2009 and are all incorporated by reference in their entireties.
One embodiment associates clusters 208 with contiguous groups of cache lines 207. However, the cluster operations can also be associated with data blocks that are not necessarily delineated on cache line boundaries. For example, the clusters 208 could be associated with blocks of data that are larger or smaller then the size of cache lines 207.
In one embodiment, all of the cache lines 207 associated with a particular cluster 208 have the same number of reads. For example, the algorithms used to derive the clusters 208 may be based on cache lines 207 having the same number of reads. In this embodiment, the processor 22 can obtain the read count value 284 from any of the cache line read count values 274 associated with that cluster 208 as shown in
The cluster last timestamp value 286 indicates a time of a most recently accessed one of the cache lines 207 associated with that particular cluster 208. The processor 22 can determine the timestamp value 286 simply by using the cache line 207 associated with that particular cluster 208 with shortest timestamp value 276.
The physical storage range 288 contains the address range for the group of cache lines 207 associated with that particular cluster 208. For example in
However, to further optimize cache resource uploading, the processor 22 uploads data into the cache resource 16 according to a generated upload list. In operation 622 the processor reads the read count value 284, last timestamp value 286, and address range value 288 for a first cluster 208. The processor in operation 624 determines if the last timestamp value 286 for the cluster 208 is older than a predetermined time limit. This could be the same or could be different than the time limit used in operation 352 of
If the last timestamp value 286 is older than the predetermined time limit in operation 624 or the read count value 284 is below the predetermined count limit in operation 626 the processor 22 moves onto the next cluster 208 in operation 638. If the last timestamp value 286 is less than the predetermined time limit and the read count value 284 is above the count limit, the processor in operation 630 creates a cluster upload list 26 shown in
If a next cluster 208 qualifies under operations 624 and 626 for adding to the cluster upload list 26, the processor 22 adds the storage range 288 of the next cluster 208 to the existing cluster upload list 26. For example, the first qualifying cluster 208 may have a storage range of 500-700 and the second qualifying cluster 208 may have a storage range of 800-1000. The cluster upload list 26 is initially created for the first cluster in operation 630 with an address range of 500-700. The cluster upload list 26 is then extended in operation 632 to an address range of 500-1000 to include the second cluster 208.
The process in operation 634 determines if the data size associated with the upload list 26 is above a predetermined size limit. The size limit may be the same or different from the size limit used in operation 362 in
Again, the processor 22 may load sub-portions of the upload data into the cache resource 16 at a time. For example, the processor 22 may read data from targets 300 in 128 KB blocks. If the cluster upload list 26 has an address range of 1 MBs, the processor 22 may read 8 separate 128 KB block of data from targets 300 and individually upload the eight 128 KB blocks of data into the cache resource 16.
The storage proxy 200 can read ten contiguous 4 KB block of data from targets 300 faster than ten 4 KB blocks of data with random non-contiguous address locations. By creating upload lists and reading groups of contiguous data blocks, the storage proxy 200 is able to further reduce the amount of time required to repopulate the cache lines 207 in the cache resource 16 with relevant data. Thus, the storage proxy 200 is able to start operating more effectively in a shorter amount of time after coming back on-line.
Hardware and Software
Several examples have been described above with reference to the accompanying drawings. Various other examples are also possible and practical. The systems and methodologies may be implemented or applied in many different forms and should not be construed as being limited to the examples set forth above. Some systems described above may use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software or firmware and other operations may be implemented in hardware.
For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software.
Digital Processors, Software and Memory Nomenclature
As explained above, embodiments of this disclosure may be implemented in a digital computing system, for example a CPU or similar processor. More specifically, the term “digital computing system,” can mean any system that includes at least one digital processor and associated memory, wherein the digital processor can execute instructions or “code” stored in that memory. (The memory may store data as well.)
A digital processor includes but is not limited to a microprocessor, multi-core processor, Digital Signal Processor (DSP), Graphics Processing Unit (GPU), processor array, network processor, etc. A digital processor (or many of them) may be embedded into an integrated circuit. In other arrangements, one or more processors may be deployed on a circuit board (motherboard, daughter board, rack blade, etc.). Embodiments of the present disclosure may be variously implemented in a variety of systems such as those just mentioned and others that may be developed in the future. In a presently preferred embodiment, the disclosed methods may be implemented in software stored in memory, further defined below.
Digital memory, further explained below, may be integrated together with a processor, for example Random Access Memory (RAM) or FLASH memory embedded in an integrated circuit Central Processing Unit (CPU), network processor or the like. In other examples, the memory comprises a physically separate device, such as an external disk drive, storage array, or portable FLASH device. In such cases, the memory becomes “associated” with the digital processor when the two are operatively coupled together, or in communication with each other, for example by an I/O port, network connection, etc. such that the processor can read a file stored on the memory. Associated memory may be “read only” by design (ROM) or by virtue of permission settings, or not. Other examples include but are not limited to WORM, EPROM, EEPROM, FLASH, etc. Those technologies often are implemented in solid state semiconductor devices. Other memories may comprise moving parts, such a conventional rotating disk drive. All such memories are “machine readable” in that they are readable by a compatible digital processor. Many interfaces and protocols for data transfers (data here includes software) between processors and memory are well known, standardized and documented elsewhere, so they are not enumerated here.
Storage of Computer Programs
As noted, some embodiments may be implemented or embodied in computer software (also known as a “computer program” or “code”; we use these terms interchangeably). Programs, or code, are most useful when stored in a digital memory that can be read by one or more digital processors. The term “computer-readable storage medium” (or alternatively, “machine-readable storage medium”) includes all of the foregoing types of memory, as well as new technologies that may arise in the future, as long as they are capable of storing digital information in the nature of a computer program or other data, at least temporarily, in such a manner that the stored information can be “read” by an appropriate digital processor. The term “computer-readable” is not intended to limit the phrase to the historical usage of “computer” to imply a complete mainframe, mini-computer, desktop or even laptop computer. Rather, the term refers to a storage medium readable by a digital processor or any digital computing system as broadly defined above. Such media may be any available media that is locally and/or remotely accessible by a computer or processor, and it includes both volatile and non-volatile media, removable and non-removable media, embedded or discrete.
Having described and illustrated a particular example system, it should be apparent that other systems may be modified in arrangement and detail without departing from the principles described above. Claim is made to all modifications and variations coming within the spirit and scope of the following claims.
This application is a continuation in part of U.S. patent application Ser. No. 12/814,438 filed on Jun. 12, 2010 which claims priority to U.S. provisional patent application Ser. No. 61/218,821 filed on Jun. 19, 2009 which are both incorporated by reference in their entirety. This application is also a continuation in part of U.S. patent application Ser. No. 12/605,119 filed on Oct. 23, 2009 that claims priority to provisional patent application Ser. No. 61/111,304 which are both herein incorporated by reference in their entirety. This application is also a continuation in part of U.S. patent application Ser. No. 12/605,160 filed Oct. 23, 2009, that claims priority to U.S. provisional patent application Ser. No. 61/111,310 which are both herein incorporated by reference in their entirety. This application is also a continuation in part of U.S. patent application Ser. No. 12/684,387 filed Jan. 8, 2010 that claims priority to U.S. provisional patent application Ser. No. 61/144,404 which are both herein incorporated by reference in their entirety.
Number | Name | Date | Kind |
---|---|---|---|
5829019 | Thompson et al. | Oct 1998 | A |
5954796 | McCarthy et al. | Sep 1999 | A |
6041366 | Maddalozzo et al. | Mar 2000 | A |
6401147 | Sang et al. | Jun 2002 | B1 |
6636982 | Rowlands | Oct 2003 | B1 |
6678795 | Moreno et al. | Jan 2004 | B1 |
6721870 | Yochai et al. | Apr 2004 | B1 |
6742084 | Defouw et al. | May 2004 | B1 |
6789171 | Desai et al. | Sep 2004 | B2 |
6810470 | Wiseman et al. | Oct 2004 | B1 |
7017084 | Ng et al. | Mar 2006 | B2 |
7089370 | Luick | Aug 2006 | B2 |
7110359 | Acharya | Sep 2006 | B1 |
7181576 | Gammel et al. | Feb 2007 | B2 |
7856533 | Hur et al. | Dec 2010 | B2 |
7870351 | Resnick | Jan 2011 | B2 |
7873619 | Faibish et al. | Jan 2011 | B1 |
7975108 | Holscher et al. | Jul 2011 | B1 |
8010485 | Chatterjee et al. | Aug 2011 | B1 |
20020035655 | Finn et al. | Mar 2002 | A1 |
20020175998 | Hoang | Nov 2002 | A1 |
20020194434 | Kurasugi | Dec 2002 | A1 |
20030012204 | Czeiger et al. | Jan 2003 | A1 |
20030167327 | Baldwin et al. | Sep 2003 | A1 |
20030177168 | Heitman et al. | Sep 2003 | A1 |
20030188219 | DeRuiter et al. | Oct 2003 | A1 |
20030210248 | Wyatt | Nov 2003 | A1 |
20040128363 | Yamagami et al. | Jul 2004 | A1 |
20040146046 | Jo et al. | Jul 2004 | A1 |
20040186945 | Jeter et al. | Sep 2004 | A1 |
20040215923 | Royer | Oct 2004 | A1 |
20050025075 | Dutt et al. | Feb 2005 | A1 |
20050195736 | Matsuda | Sep 2005 | A1 |
20060005074 | Yanai et al. | Jan 2006 | A1 |
20060034302 | Peterson | Feb 2006 | A1 |
20060053263 | Prahlad et al. | Mar 2006 | A1 |
20060075191 | Lolayekar et al. | Apr 2006 | A1 |
20060112232 | Zohar et al. | May 2006 | A1 |
20060143432 | Rothman et al. | Jun 2006 | A1 |
20060212524 | Wu et al. | Sep 2006 | A1 |
20060218389 | Li et al. | Sep 2006 | A1 |
20060277329 | Paulson et al. | Dec 2006 | A1 |
20070050548 | Bali et al. | Mar 2007 | A1 |
20070079105 | Thompson | Apr 2007 | A1 |
20070118710 | Yamakawa et al. | May 2007 | A1 |
20070124407 | Weber et al. | May 2007 | A1 |
20070192444 | Ackaouy et al. | Aug 2007 | A1 |
20070233700 | Tomonaga | Oct 2007 | A1 |
20070283086 | Bates | Dec 2007 | A1 |
20080028162 | Thompson | Jan 2008 | A1 |
20080098173 | Chidambaran et al. | Apr 2008 | A1 |
20080104363 | Raj et al. | May 2008 | A1 |
20080162864 | Sugumar et al. | Jul 2008 | A1 |
20080215827 | Pepper | Sep 2008 | A1 |
20080215834 | Dumitru et al. | Sep 2008 | A1 |
20080250195 | Chow et al. | Oct 2008 | A1 |
20080320269 | Houlihan et al. | Dec 2008 | A1 |
20090006725 | Ito et al. | Jan 2009 | A1 |
20090006745 | Cavallo et al. | Jan 2009 | A1 |
20090034377 | English et al. | Feb 2009 | A1 |
20090110000 | Brorup | Apr 2009 | A1 |
20090240873 | Yu et al. | Sep 2009 | A1 |
20090259800 | Kilzer et al. | Oct 2009 | A1 |
20090262741 | Jungck et al. | Oct 2009 | A1 |
20090276588 | Murase | Nov 2009 | A1 |
20090307388 | Tchapda | Dec 2009 | A1 |
20100011154 | Yeh | Jan 2010 | A1 |
20100030809 | Nath | Feb 2010 | A1 |
20100080237 | Dai et al. | Apr 2010 | A1 |
20100088469 | Motonaga et al. | Apr 2010 | A1 |
20100115206 | de la Iglesia et al. | May 2010 | A1 |
20100115211 | de la Iglesia et al. | May 2010 | A1 |
20100122020 | Sikdar et al. | May 2010 | A1 |
20100125857 | Dommeti et al. | May 2010 | A1 |
20100169544 | Eom et al. | Jul 2010 | A1 |
20100174939 | Vexler | Jul 2010 | A1 |
20110047347 | Li et al. | Feb 2011 | A1 |
20110258362 | McLaren et al. | Oct 2011 | A1 |
20120198176 | Hooker et al. | Aug 2012 | A1 |
Entry |
---|
Mark Friedman, Odysseas Pentakalos. Windows 2000 Performance Guide. File Cache Performance and Tuning [reprinted online]. O'Reilly Media. Jan. 2002 [retrieved on Oct. 29, 2012]. Retrieved from the internet: <URL:http://technet.microsoft.com/en-us/library/bb742613.aspx#mainSection>. |
Stolowitz Ford Cowger Listing of Related Cases, Feb. 7, 2012. |
Rosenblum, Mendel and Ousterhout, John K., The LFS Storage Manager. Proceedings of the 1990 Summer Usenix. 1990 pp. 315-324. |
Number | Date | Country | |
---|---|---|---|
61218821 | Jun 2009 | US | |
61111304 | Nov 2008 | US | |
61111310 | Nov 2008 | US | |
61144404 | Jan 2009 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12814438 | Jun 2010 | US |
Child | 12889732 | US | |
Parent | 12605119 | Oct 2009 | US |
Child | 12814438 | US | |
Parent | 12605160 | Oct 2009 | US |
Child | 12814438 | US | |
Parent | 12684387 | Jan 2010 | US |
Child | 12814438 | US |