Patent Publication Number: US-9411518-B2

Title: Method, computer program product and apparatus for accelerating responses to requests for transactions involving data operations

Description:
CROSS REFERENCES TO RELATED APPLICATIONS 
     This is a Continuation Application of U.S. patent application Ser. No. 12/826,892, filed on Jul. 1, 2010 and now U.S. Pat. No. 8,862,813, issued Oct. 14, 2014, which is a Continuation Application of U.S. patent application Ser. No. 11/319,734, filed on Dec. 29, 2005, and now U.S. Pat. No. 7,752,386 issued Jul. 6, 2010. All of the above applications are incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates generally to responding to input/output requests made by computer applications, and more particularly to accelerating the performance of applications in relation to input/output requests received by an operating system from one or more applications. 
     2. Description of the Related Art 
     Computer applications continue to consume and rely upon an increasing amount of computational resources. Significant contributors to application performance include processor speed, memory, network bandwidth, and disk input and output (“I/O, or “IO”). The decreasing cost of storage capacity has helped to ensure that enough storage remains available to applications. Unfortunately, improvements in disk IO performance (the rate at which a system reads data from and writes data to disk drives) have not kept pace with performance improvements in other computational resources, such as processor speed, memory size and speed, and network bandwidth, which improve by orders of magnitude every few years. As a result, many computer bottlenecks are now solely or largely due to inadequate disk IO performance. This, in part, is because mechanical operations are required for a disk drive to perform its tasks that slow performance to mechanical speeds, but these other computational resources operate at electronic speeds. 
     Various efforts have been made to ameliorate some of the latencies that result when IO requests involve physical storage. Storage caches in external storage subsystems, file system caches, and RAM disks are all well known. Each of these efforts may improve responsiveness at some point in the chain between an application making an IO request and the corresponding physical storage, but the IO performance bottleneck from the perspective of the application persists. 
     For example, certain storage subsystems external to the computer system employed technologies, each designed specifically for the proprietary subsystem on which it is used (thus, not transferable to commodity systems), that improved the responsiveness of IO requests to the proprietary subsystem&#39;s disks. But this improvement only begins after the IO request has “crossed the wire” connecting the computer system to the storage subsystem and it ends when the response from the subsystem to the request again reaches the wire on its way out of the subsystem. The latencies of transport of the request across the wire persist and it does nothing to improve IO performance on the other side of the wire, within the computer system. 
     RAM disks seek to improve disk IO performance by overcoming the latencies associated with mechanical disk drives. However, they too have problems that make them impractical or inadequate to solve the application IO bottleneck problem. With RAM disks, performance improvements come at a very high cost, making the solution cost prohibitive to most. They are difficult and laborious to implement, because the RAM disk relies upon user configuration or “tuning” of the system. Specifically, the user operates “hotfile” software to identify a list of most frequently accessed files to place on the RAM disk. The user must also manage which files will need to be moved to RAM disk, and the hardware connections to the RAM disk to ensure realization of the available performance improvements. Ongoing tuning is required to optimize RAM disk performance since the files that are currently “hot” may not be the same as those that are hot in the future. Finally, it is not efficient. It speeds IO by being a faster type of disk; it does not have the intelligence to know which applications are most susceptible to bottlenecks or how to improve IO performance based upon the requirements of such applications. Therefore, even though it increases IO speeds, it does so indiscriminately, and is not able to concentrate performance improvement on the IO requests that will have the most impact on the performance of the application. 
     Finally, the file system cache is useful, but has significant limitations, particularly for storage intensive operations, as the file system cache operates in a different context (files) from that used by the physical disks. Moreover, the file system cache is essentially passive, seeking to store as many files as allocation accommodates, and, like the RAM disk, does not lend itself to efficiency because it is not cognizant of or able to adjust to the specific IO requirements of individual applications. 
     Accordingly, while there have been various advances in the provision of faster responsiveness to application IO requests, there are many remaining problems and the disk IO performance bottleneck persists. 
     SUMMARY OF THE INVENTION 
     The present invention provides systems, methods and apparatus for accelerating the performance of applications. 
     According to one aspect, the present invention accelerates performance of an application in relation to IO requests made by the application to an operating system in a computing device (e.g., an application server or desktop computer), by providing a disk block cache that is provided in the system memory of the computing device. In one embodiment, this application performance acceleration is accommodated by interfacing with the logical disk and physical disk management components of the operating system of the computing device, and within that pathway providing the system memory-based disk block cache. 
     Interfacing with the logical disk management component of the operating system identifies logical disk addresses for IO requests made from an application to the operating system. These addresses are translated to physical disk addresses that correspond to disk blocks available on a physical storage resource. The disk block cache stores cached disk blocks that correspond to the disk blocks available on the physical storage resource. Interfacing with the physical disk management component of the operating system accommodates managing the coherence of disk blocks in the disk block cache with the physical storage resource, which may involve management of the exchange of data with the physical storage resource pursuant to maintenance of the disk block cache and fulfillment of the IO requests. 
     According to another aspect, the interfacing with the logical and physical disk management components is transparent, such that the logical disk management component and the physical disk management component operate as though they were directly interfacing with each other, without the intermediate functionality performed by IO performance acceleration. The proximity of the disk block cache to the host system and the transparent interfacing with the logical and physical disk components with the operating system accommodate IO request responsiveness that is not available with existing systems and techniques, and that traverses the particular requirements of the various applications, as well as the various types of storage, that may be involved in connection with IO requests. 
     According to another aspect, application performance acceleration accommodates improved responsiveness for IO requests from any number of various applications, and does so transparently through the logical disk management component of the operating system, without requiring a separate configuration for each application. The applications (directly or indirectly such as through an API) merely refer to the logical disk management component of the operating system in the usual fashion and the application performance acceleration functionality expedites IO request responsiveness. 
     According to still another aspect, the physical storage resources may comprise multiple different disks. Here, managing the exchange of data with the physical storage resource is commonly provided for each of the different disks transparently through the physical disk management component of the operating system, without requiring a customization of the application performance acceleration functionality for individual ones of the different disks. 
     Provision of the disk block cache in the pathway between the logical disk and physical disk management components of the operating system of the computing device accommodates IO request performance improvement that looks upward to the applications making IO requests and looks downward to the corresponding physical storage. This upward looking aspect to the disk block cache provides a disk block cache that tailors to each application&#39;s need, and the downward looking aspect provides a disk block cache that flexibly accommodates interaction with various different physical storage devices to which the computing device may connect. 
     The present invention can be embodied in various forms, including computer implemented methods, computer program products, computer systems and networks, user interfaces, application programming interfaces, and the like. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other more detailed and specific features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which: 
         FIG. 1  is a block diagram illustrating a computer system having a performance acceleration module in accordance with the present invention. 
         FIG. 2  is a block diagram illustrating an embodiment of a performance acceleration module in accordance with the present invention. 
         FIG. 3  is a flow diagram illustrating an embodiment of performance acceleration for handling an IO request in accordance with the present invention. 
         FIGS. 4A-B  are flow diagrams illustrating an embodiment of managing a system memory disk block cache pursuant to performance acceleration in accordance with the present invention. 
         FIG. 5  is a block diagram illustrating an example of a system in which a performance acceleration module operates in accordance with the present invention. 
         FIG. 6  is a block diagram illustrating another example of a system that includes a SQL server configured to include a performance acceleration module in accordance with the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In the following description, for purposes of explanation, numerous details are set forth, such as flowcharts and system configurations, in order to provide an understanding of one or more embodiments of the present invention. However, it is and will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention. 
       FIG. 1  is a block diagram illustrating a computer system  100  having a performance acceleration module  120  in accordance with the present invention. According to one aspect of the present invention, the performance acceleration module  120  interfaces with an operating system and maintains a disk block cache in system memory to expedite the fulfillment of IO requests received by the operating system from one or more applications. 
     In addition to including a processor and memory,  FIG. 1  illustrates the computer system  100  to include a variety of operating system components  102 - 116  useful in connection with a description of the present invention. In one embodiment, the operating system is a Windows operating system as provided by Microsoft Corporation of Redmond, Wash. (e.g., Windows XP, Windows 2000; Windows 2003 series). Alternative operating systems include but are not limited to those implemented with Apple computers as provided by Apple Corp., Cupertino, Calif., and UNIX-based systems. 
     The operating system includes an interface module  102 , file system  104 , file system cache  106 , raw disk access module  108 , logical disk management module  110 , physical disk management module  112 , and a physical disk adapter management module  114 . The operating system also includes other functions  116  that need not be delineated herein for an understanding of the present invention. 
     The interface module  102  accommodates receipt and delivery of instructions from users and applications. With regard to applications, the interface may be embodied as a set of application programming interfaces (APIs) through which requests are made to the operating system, in lieu of a graphical user interface or command interface. As illustrated in the figure, a number of applications  118   a - c  may interface with the operating system. Among the requests made by applications  118   a - c  are IO requests, which include read requests and write requests. 
     The file system  104  accommodates the naming and logical placement of files for storage and retrieval, typically invoking a number of directories arranged in hierarchical fashion. 
     The file system cache  106  provides a conventional file system cache, which is an allocated portion of memory that retains recently used information. The size of the cache may depend upon the amount of physical memory available as well as the amount of memory used by installed applications. The file system cache  106  may be fixed or dynamically adjusted by the operating system according to need. 
     The raw disk access module  108  accommodates alternative storage access. With the operating system, an application may use different ways to access physical storage. One is through the file system  104 . The other is to more directly access physical storage through the raw disk access module  108 . 
     The logical disk management module  110  accommodates the creation and management of partitions and logical volumes corresponding to available disks. Interfaces allow that the creation of new partitions and logical drives, as well as formatting and other configuration of created partitions and drives. 
     The physical disk management module  112  maps logical disks to the physical disks, and the physical disk adapter management module  114  accommodates management of the connections to the actual physical disks. The operating system recognizes the different physical disk entities that are connected via the physical disk management module  112 , which basically tracks them as physical disk objects (i.e., it identifies disk blocks). The physical disk adapter module  114  is essentially a set drivers for the particular disk(s) to which the operating system is connected. There may be as many drivers as there are types of connected disks. The module also translates to the language used by the disk. For example, a SCSI interface, may be slightly different from a Fibre channel interface, etc. The physical disk adapter module  114  may also include one or more HBA cards to accommodate the connection to the physical disks. 
     The performance acceleration (PA) module  120  interfaces with the logical disk management module  110  and the physical disk management module  112  of the operating system, and at that juncture manages a disk block cache that resides within the computer system  100  memory. 
     Maintenance of the disk block cache includes the management of reads and writes, as well as corresponding physical disk access (pre-fetching and de-staging of blocks). The disk block cache may include as many disk blocks as possible, subject to the limitation of how much memory is allocated to the PA module  120  for the disk block cache. A physical disk block in most modern systems is 512 bytes. The disk block cache may also work with multiples of physical disk blocks to provide consistency and compatibility with the operating system. For example, the disk block cache may implement 4K blocks for compatibility with a file system that uses 4K blocks. In such an embodiment, each 4K block within the disk block cache actually contains 512 byte physical disk blocks. 
     The PA module  120  also interfaces between logical disk and physical disk management components of the operating system to further expedite storage access rates. In that regard, the expedited fulfillment of IO requests made by an application to an operating system includes interfacing with the logical disk management component of the operating system to identify logical disk addresses for IO requests sent from the application to the operating system. These addresses are then correlated to physical disk addresses that correspond to a plurality of disk blocks available on a physical storage resource. As described, the disk block cache stores a plurality of cached disk blocks that correspond to the plurality of disk blocks available on the physical storage resource. The PA module  120  interfaces with the physical disk management component of the operating system to accommodate managing the exchange of data with the physical storage resource pursuant to maintenance of the disk block cache and fulfillment of the IO requests. 
     The PA module  120  is preferably a filter class driver that is integrated with the operating system. Although the performance acceleration module is interposed between the logical disk management module  110  and the physical disk management module  112 , the interfacing with those components is transparent. Because of this, the logical disk management module  110  does not require modification and operates as though it is directly communicating with the physical disk management module  112 , and vice-versa. 
     Additionally, communications with the logical disk management module  110  and the physical disk management module  112  can respectively made by applications and physical storage resources in traditional fashion. This allows provision of the performance acceleration functionality for different applications and storage resources (e.g., different types of disks) without requiring a modification in the way that the applications and storage resources communicate with the operating system. Even if different HBAs are used for different disk sets, the performance acceleration functionality is still provided without requiring additional modification. That is, the physical disk management module  112  generally interfaces with the HBA components in the usual fashion. 
     Provision of the disk block cache in the pathway between the logical disk and physical disk management components of the operating system of the computing device accommodates IO request performance improvement that looks upward to the applications making IO requests and looks downward to the corresponding physical storage. This upward looking aspect to the disk block cache provides a disk block cache that tailors to each application&#39;s need, and the downward looking aspect provides a disk block cache that flexibly accommodates interaction with various different physical storage devices to which the computing device may connect. The transparent interfacing with the logical and physical disk components with the operating system accommodate IO request responsiveness that is not available with existing systems and techniques, and that traverses the particular requirements of the various applications, as well as the various types of storage, that may be involved in connection with IO requests. 
     The PA module  120  may reside in various types of computing devices including desktop and laptop computers, servers, digital televisions, network appliances, and others. 
       FIG. 2  is a block diagram illustrating an embodiment of a performance acceleration (PA) module  200  in accordance with the present invention. 
     The PA module  200  runs on a conventional operating system in memory and carries out the described functionality by execution of computer instructions. The artisan will readily recognize the various alternative programming languages and execution platforms that are and will become available, and the present invention is not limited to any specific execution environment. 
     The PA module  200  is preferably a filter class driver that integrates with the operating system in the described fashion. Although one modular breakdown is described, such is provided by way of example only, as the functionality of the PA module  200  may be provided in any number of alternative designs having greater, fewer or differently named component modules. 
     The PA module  200  may be variously embodied. In one example, a computer system includes the PA module  200  resident in memory on a conventional computer system, with the PA module  200  including instructions that are executed by a processor. Alternative embodiments include an article of manufacture where the PA module  200  instructions are stored on a computer readable storage medium. The medium may be of any type, including but not limited to magnetic storage media (e.g., floppy disks, hard disks), optical storage media (e.g., CD, DVD), and others. Other embodiments of this aspect of the present invention include computer implemented processes described in connection with the PA module  200  as well as the corresponding flow diagrams. 
     The PA module  200  includes a logical disk translation layer  202 , a physical disk block mapping (PDBM) module  204 , a write management module  206 , a read management module  208 , an optimized block IO management (OBIM) module  210 , a dirty data de-stage management (DDSM) module  212 , and a data pre-fetch management (DPFM) module  214 . 
     Physical disk map tables  216  and the disk block cache  218  are preferably stored in memory, and managed by the PA module  200  as described. The physical disk map tables  216  are the data structures that maintain coherency and consistency of the data in memory with the data that is (presently or ultimately) on the disks. The disk block cache  218  is the in-memory copy of the most recently read and dirty write data to be de-staged to the disks. 
     The logical disk translation layer  202  maps file system IO requests that are described according to logical disk addresses into the physical disk addresses. Basically, the top end entry point to the PA module  200  is seen as an IO request to a logical address. The logical disk translation layer  202  translates into a physical address so that other modules can appropriately handle reads and writes and related queuing and removal of the same as described further below. 
     The PDBM module  204  performs IO request processing. With regard to read requests, the PDBM module  204  does a hash table look up to see whether the requested data is locally available (i.e., in the disk block cache). It also performs single and multiple streaming read analysis for pre-fetch activation from disks. Single stream pre-fetch uses an inference that a number of sequential blocks will be read by an application based upon an existing read pattern. Multiple streaming pre-fetch is an enhancement to single stream, and uses analysis of seemingly random IO requests to identify several distinct sequential block accesses (typically by multiple applications concurrently making IO requests). In contrast to disk controller cache partitioning, which can support multiple streaming pre-fetch, the location of the disk block cache (at the site of the requesting application(s)) and the flexibility and size of the disk block cache potentially support multiple stream pre-fetching that is both more diverse and more efficient than is possible in a disk controller cache. 
     For write requests, the PDBM module  204  does a hash table look up for write data block reuse, and uses least recently used (LRU) manipulation to allocate write data blocks. 
     The OBIM module  210  manages the ordering of cached data to support dirty data reuse, pre-fetch, and dirty data queuing. To accommodate the ordering of data, the OBIM module  210  reorders cache blocks and marks data within cache blocks as either valid, valid-dirty or invalid. Generally, valid indicates that whatever is in the cache block is the most recent information and matches the corresponding content on the physical disk. Valid-dirty, which may also be referred to as dirty, means that that there is data in the cache that has not yet been de-staged to the physical disk. Invalid means that a block is in transition and that time must lapse before the relevant block may be read from or written to. 
     The OBIM module  210  also manages the hash list of LRU and most recently used (MRU) data blocks. It performs read pre-fetching to satisfy predicted read requests and large block write requests to increase throughput. Finally, it dynamically manages the read and write queues to prevent read IO stalls. 
     The DDSM module  212  and DPFM module  214  respectively handle the actual IO requests to the physical disks. They manage the initiation and completion of IO requests, and coordinate the arrival of read data, and de-staging of dirty write data between the disk block cache  218  and the disks. 
       FIG. 3  is a flow diagram illustrating an embodiment of handling an IO request with disk block cache management  300  in accordance with the present invention, such as provided by the previously introduced PDBM module. 
     The process  300  commences with the receipt  302  of an IO request, which may be a read or a write. The IO request is received in terms of a logical disk address, which is translated  304  to a physical disk address. The physical disk address corresponds a disk block on the physical storage resource. The singular term block is used below for ease of description, although it should be understood that multiple blocks may be involved. 
     Following determination of the physical disk address, a cache table lookup  306  accommodates a determination whether the corresponding block is resident in the disk block cache. A determination  308  of a cache hit prompts appropriate hash list (LRU, MRU) manipulation and processing of the IO request using the block already found in the cache. Specifically, the hash listing is reordered  310  to reflect that the current block was most recently used. 
     Then, it is determined  312  whether the IO request is a read or a write. For a read request, the data is copied  314  from the relevant disk block in the disk block cache to an IO Request Buffer. The IO Request Buffer may store and accumulate data corresponding to read requests (as well as write requests). A Read Request Complete indication  316  confirms the completion of the read. 
     For a write request, the relevant disk block in the cache is marked  318  as dirty. This indicates that, because of the write, the disk block in the cache differs from its counterpart on the physical storage resource (e.g., disk). The IO Request Buffer stores data corresponding to the write request. This data is copied  320  to the relevant disk block in the disk block cache. This disk block remains dirty until it is appropriately de-staged as discussed further below. In association with the management of disk block de-staging, the write request is communicated  322  to the OBIM module. Finally, a Write Request Complete indication  324  confirms the completion of the write. 
     A cache miss determination  308  means that the relevant disk block is not currently in the cache. The disk block cache has memory allocation for numerous disk blocks, as described. A cache block is allocated  326  from the free list and is marked invalid, since the corresponding disk block has not yet been fetched from the physical storage resource. Following this, if the IO request is determined  328  to be a read, then the read request is issued  330  to the OBIM, which manages the exchange of data (pre-fetching, de-staging, etc.) with the physical storage resource. In the interim, a Read Request Pending indication  332  communicates the need to wait for the retrieval of the relevant disk block and therefore the data corresponding to the read request. 
     For a write request determination  328 , the processing is the same as described above for the cache hit process, wherein the disk block is marked  330  dirty, the data is copied  320  to the disk block in the cache and the write request is issued  322  to the OBIM. The write request will be an integer number of disk blocks. In this situation the disk block in the cache is the new content of what should be on disk. Marking the disk block as dirty essentially marks what is on physical disk as no longer valid (until de-staging). 
       FIGS. 4A-B  are flow diagrams illustrating an embodiment of managing the disk block cache in accordance with the present invention. This functionality may be performed by the previously described OBIM module. The OBIM module interfaces with the PDBM module in connection with application-initiated IO requests, and interfaces with physical storage resources (e.g., a disk controller) in connection with completion of IO requests. The corresponding processes  400   a ,  400   b  are respectively illustrated in  FIG. 4A  and  FIG. 4B . The OBIM module manages the hash list of LRU and MRU data blocks, performs read pre-fetching to satisfy predicted read requests and large block write requests to increase throughput, and dynamically manages the read and write queues to prevent read IO stalls. 
     Initially referring to  FIG. 4A , following receipt  402  of the IO request, it is determined  404  whether the request is a read or a write. The relevant disk block in the cache is linked  406  to the read queue managed by the OBIM. The read queue generally would fulfill the requests to read disk blocks in the order in which they are received, subject to read queue pre-fetch processing  408  and read queue versus in-flight IO processing  410  operations. These operations allow disk blocks to be read out of order where it is determined that pre-fetching would be more efficient, and allows in-flight processing to give priority to certain requests. Priority may be given to prevent IO stalls. 
     If there are reads or writes that are contiguous but in separate requests, they are preferably combined into one read request or write transaction. Priority is also typically leveraged between reads and writes, more than from read to read. Generally, the in-flight processing is biased to a read because of the need for responsiveness to the application. Writes that are going to disk are really completed writes as far as the application is concerned. It is also preferable to ensure that the queue is not filled with a greater number of writes as opposed to reads. This is to avoid having a lot of writes ahead of the read in the queue. To accommodate this, the number of writes in the queue may be limited to a predetermined amount. This can also be configured to be dynamic, where the system increases the write queue limit in the absence of reads, and then returns to the lower limit if reads return. 
     In lieu of specific algorithms for specific applications, the performance acceleration module of the present invention preferably seeks to satisfy the largest group of applications to give the best overall performance. Although any algorithm may be implemented in accordance with the present invention, it is believed that a basic LRU algorithm may be the most efficient and flexible for most applications. 
     Subject to these processes, it is determined  412  whether to issue a read IO for the given disk block, whereupon a physical read IO request is issued  414  to the physical storage resource, or processing returns  416  to consideration of additional operations. 
     For a write operation determination  404 , the relevant disk block in the disk block cache is linked  418  to the write queue. Write queue coalescing  420  accommodates efficient write operations by minimizing the amount of times that actual access to the physical storage resource must be made. Write queue versus in-flight IO processing  422  also accommodates priority to certain IO requests. It is determined  424 , similarly subject to such processes, whether to issue a write IO for a given disk block in the cache, whereupon a physical write IO request is issued  426  to the physical storage resource. 
     Managing the disk block cache in the above-described fashion accommodates a minimization of the number of IO transactions that are issued to the physical storage resource to fulfill the corresponding IO requests processed by the PA module. For example, the write coalescing and read pre-fetching performed by the PA module involve the tracking of IO access patterns so that the IO requests can be combined as part of larger IO transactions that are actually issued to the disk. This provides a reduction in the number of actual IO transactions that are issued to the disk in relation to the IO requests. 
     This reduction in the number of application IO transactions that are issued to the physical disks translates into better bandwidth utilization of the connecting medium used to access the disk as well more efficient disk access, which reduces mechanical latencies. All IO transactions incur an overhead that includes transmission protocol bandwidth as well as mechanical latencies associated with the disk (head seek and disk rotational latencies). Therefore, the ability to cache many small sized IOs requested by applications into larger sized transactions to the disk helps to improve the overall bandwidth of the connection as well as the throughput of the disk device. 
       FIG. 4B  illustrates processing  400   b  following completion of the IO transaction by the physical storage resource (e.g., as communicated by a disk controller). Following receipt  430  of an indication of IO completion from the disk controller, the corresponding disk block is marked  432  as valid in the hash listing. For a read operation determination  434 , the retrieved disk block now resides in the disk block cache and may be copied  436  to the IO Request Buffer whereupon a Read Request Complete indication may be returned  438 , removing the pending status of the read operation as previously described. For a write operation, the presence of the disk block in the disk block cache accommodates write requests to the now valid block, so no operation is required. 
       FIG. 5  is a block diagram illustrating an example of a system  500  in which a performance acceleration module operates in accordance with the present invention. A host system  500  is a computer system including a processor  520  and memory  540 . The host system  500  includes an operating system  534  such as those previously described, as well as memory  530 . Application(s)  632  including but not limited to those for word processing, mathematical calculation, drawing and multimedia content (e.g., video and/or audio) may be provided by the host system  500 . The host system  500  may be directly operated by a user. The host system  500  may also be accessed by other computers through a network connection, in which case the host system  500  may also be referred to as an application server. 
     The host system  500  is also in communication with physical storage  540 . Physical storage may include hard disks, optical disks, and other types of storage. The PA module  536  accommodates the expedited fulfillment of IO requests for the host system applications  532 . Through the operating system  534 , the PA module  536  receives an IO request from an application  532 . 
     The IO request has a logical disk address. The PA module  536  correlates the logical disk address to a physical disk address. The physical disk address corresponds to the physical storage  540 , which may include a number of physical disk sets  542 - 6 . The physical storage  540  uses physical disk blocks as a unit of storage. The physical disk address for the IO request will correlate to one or more of these blocks. 
     The PA module  536  also maintains a disk block cache that stores a plurality of disk blocks that directly correspond to the disk blocks that are stored in physical storage  540 . Generally, the PA module  536  determines whether the physical disk block for an IO request is represented among the plurality of disk blocks in the disk block cache. If such is the case, a disk block cache hit results, and the PA module  536  fulfills the IO request for the application without requiring an immediate interaction with the physical storage  540 . As described further above, the PA module  536  also preferably uses techniques for managing the disk block cache, as well as corresponding queues for de-staging and pre-fetching in response to various IO requests. 
     According to another aspect, the PA module  536  accommodates the expedited fulfillment of IO requests in conjunction with systems  500  that include varied physical storage assets, without requiring PA module  536  customization for each particular type of storage to which the system is connected. Rather, any customization in this regard can be provided using configuration of the physical disk management and physical disk adapter management modules, such as through provision of drivers for the particular types of disks in those modules. Thus, the host system  510  is configurable for communication with physical disk sets  542 ,  544 ,  546  of different types. 
     As described previously, the PA module may be resident in desktop, server, and other computing environments. Server embodiments include but are not limited to virtual server solutions (e.g., Microsoft Virtual Server, VMware®); thin-client server solutions (e.g., Citrix® MetaFrame® Presentation Server, Microsoft Terminal Server); messaging and collaboration servers (e.g., IBM Lotus Domino Server); database servers (e.g., Microsoft SQL Server, IBM DB2, etc.); business intelligence servers; web servers (e.g., Microsoft Internet Information Services, Apache HTTP); and cluster servers. Additionally, although certain applications are described herein, it is noted that the PA modules described herein may operate with various applications including but not limited to multimedia applications (e.g., music, movies etc.), video editing, office software suites, database applications, mail and messaging applications, e-commerce and financial applications, web serving and hosting applications, and others. 
       FIG. 6  is a block diagram illustrating another example of a system  600  wherein expedited fulfillment of IO requests made by an application is accommodated. Here, the application is a database application. Particularly, the system  600  includes a database server  610  (e.g., a SQL server) that includes a processor  620  and memory  630  to carry out the described functionality. The database server  610  receives requests from a client computer  660  typically through a network connection such as a Local Area Network (LAN) or the Internet. In the Internet example the database server  610  is configured for communication with the client computer  660  using conventional network protocols and related software. The request may, for example, be initiated through a client computer  660  browser. Alternatively, a client computer  660  may initiate a request through a Web server (not shown), which in turn would communicate with the database server  610  to respond to the request. There are various architectures and protocols for receiving and responding to requests for data involving a database. The present invention may be practiced in the context of any such system for receiving and responding to requests for data, including existing systems and those to be developed. 
     The database server  610  memory  630  is configured to include a data request application  640  and an operating system  650  further configured to include a PA module  652 . The PA module  652  includes the features described in connection with  FIG. 2  above, and similarly resides in the pathway between the logical and physical disk management components of the operating system  650  to accommodate the provision of expedited responsiveness to IO requests through management of a memory  630  resident disk block cache as described. 
     The database server  610  is in communication with physical disk set(s)  670  that store the database content  672 . The database content  672  includes conventional components such as a database management system  674 , a database index  676  and the database tables  678 . Typically, the database server  610 , and more particularly the data request application  640 , responds to a request by accessing the physical disk set(s)  670  to retrieve data contained in the database tables  678 , by interfacing with the database management system  674  which in turn uses the database index  676  to organize and access the data. 
     A known technique for improving database request response times is to use a database cache on the database server  610  system side (i.e., a cache that would reside in the database server  610  memory  630 ). In this fashion, as much memory as possible is allocated for a cache of the database tables  678 , in an effort to avoid the delays associated with retrieving the data from the physical disk set(s)  670  when the data is requested. Unfortunately, systems do not have enough memory to accommodate an entire typical database. There is inevitably a database cache miss and the corresponding cost of physical disk data retrieval. 
     In lieu of (or in conjunction with) allocating a relatively large database cache dedicated to the contents of the database  672 , responsiveness is improved by using available memory  630  for a disk block cache managed by the PA module  652 . Allocating memory in this fashion, in conjunction with the features of the PA module  652  in accordance with the present invention, improves on response times that would be provided by a system using a conventional database cache. This is because the PA module  652  generally ameliorates the cost of accessing the physical disk set(s)  670 . 
     Note that the PA module  652  may also work in conjunction with other techniques for improving performance. For example, many database servers perform intermediate operations in temporary database files, with server performance being constrained by the ability to access temporary database files Implementing these files in conjunction with the PA module  652  allows the performance improvements available through usage of temporary files to be extended by avoiding latencies that would have occurred in the absence of the PA module  652 . Similarly, the PA module  652  can operate in conjunction with a system using the file system cache, to alleviate stresses that applications would ordinarily place on the file system cache. For example, for database applications for large, frequently accessed databases the PA module  652  can alleviate table file access delays that would typically be encountered in the absence of the PA module  652 . 
     Thus embodiments of the present invention produce and provide performance acceleration in connection with requests by applications corresponding to physical storage resources. Although the present invention has been described in considerable detail with reference to certain embodiments thereof, the invention may be variously embodied without departing from the spirit or scope of the invention. Therefore, the following claims should not be limited to the description of the embodiments contained herein in any way.