Abstract: Aspects of the subject matter described herein relate to client-side caching. In aspects, when a client receives a request for data that is located on a remote server, the client first checks a local cache to see if the data is stored in the local cache. If the data is not stored in the local cache, the client may check a peer cache to see if the data is stored in the peer cache. If the data is not stored in the peer cache, the client obtains the data from the remote server, caches it locally, and publishes to the peer cache that the client has a copy of the data.

Abstract: The present invention extends to methods, systems, and computer program products for end-to-end optimization of data storage and transmission of data. Details of how data is stored within a data store are exposed to clients and applications. Clients and applications are enabled to makes requests to data stores to obtain data as it is actually stored upon within the data store to eliminate redundant processing of the requested data. Compression and de-duplication of data within a data store are leveraged to increase the efficiency and reduce latency of data transmitted over a LAN or WAN.

Abstract: A model in which filter drivers are managed to receive callbacks for I/O requests in which the filter drivers have registered an interest. Per-volume instances of filter drivers register with a filter manager for pre-callbacks (for I/O to the file system) and post-callbacks (for I/O from the file system), and identify which I/O requests (e.g., create, read, write) they are registering to receive callbacks. The filter manager orders the instances for callbacks. When an I/O request is received, the filter manager converts the I/O request to callback data and calls the interested filters in the callback order, whereby the filter instances can process the I/O data. As the request returns from the file system, filters desiring post callbacks are called in the reverse order. Efficient context management for the filters and other functions, such as non-reentrant file I/O, are also provided by the model.

Abstract: Aspects of the subject matter described herein relate to client-side caching. In aspects, when a client receives a request for data that is located on a remote server, the client first checks a local cache to see if the data is stored in the local cache. If the data is not stored in the local cache, the client may check a peer cache to see if the data is stored in the peer cache. If the data is not stored in the peer cache, the client obtains the data from the remote server, caches it locally, and publishes to the peer cache that the client has a copy of the data.

Abstract: Described is a method and system that manages filenames for filter drivers in a file system. The present invention includes a filter manager that handles filename queries from the filter drivers. The filter manager returns a pointer to the requesting filter driver that points to a filename information structure corresponding to the type of filename requested. The filter manager also manages a cache of filename information structures that include information that can be shared among the various filter drivers, amortizing the filename queries for filter drivers. The caching functionality of the filter manager increases the efficiency and reduces the overhead of filename queries within the file system by reducing the number of filename operations required for a file system filter driver to retrieve a desired portion of the filename.

Abstract: The invention provides a system and method for dynamically unloading file system filters in a stacked-call-back model where filters are stacked one on top of the other to form a filter stack. A filter manager keeps track of the progress of each I/O operation and calls each filter in turn with the filter returning after it has completed processing the given operation. The filter manager dynamically unloads a filter (or an instance of a filter) that is positioned at any position in the filter stack in a reasonable amount of time while I/O operations are actively being processed. The filter/filter instance can be unloaded with outstanding I/O operations on the filter either hosted by the filter or pended by other filters. I/O operations are canceled, completed or drained in order to unload the filter or filter instance. A filter may veto the unloading of the filter.

Abstract: A method and system for ordering software modules in a guaranteed order for execution. Unique values are statically assigned to software modules (e.g., filter drivers) when fully developed. Each module's assigned value determines its relative position to other modules in a stack or other arrangement, fixing the execution order for any set of filter drivers. Static values may comprise floating-point numbers, whereby each new software module may be assigned a number that enables positioning it between any two existing software modules. For example, filter drivers may be generally classified and assigned values in a range according to type. Drivers of the same type may be ordered within their general range to guarantee one possible ordering. A filter manager architecture is described, in which filter drivers register with a manager for relevant file system I/O operations. The manager calls appropriately registered filter drivers in an order based on their assigned numbers.

Abstract: A model in which filter drivers are managed to receive callbacks for I/O requests in which the filter drivers have registered an interest. Per-volume instances of filter drivers register with a filter manager for pre-callbacks (for I/O to the file system) and post-callbacks (for I/O from the file system), and identify which I/O requests (e.g., create, read, write) they are registering to receive callbacks. The filter manager orders the instances for callbacks. When an I/O request is received, the filter manager converts the I/O request to callback data and calls the interested filters in the callback order, whereby the filter instances can process the I/O data. As the request returns from the file system, filters desiring post callbacks are called in the reverse order. Efficient context management for the filters and other functions, such as non-reentrant file I/O, are also provided by the model.

Abstract: A model in which filter drivers are managed to receive callbacks for I/O requests in which the filter drivers have registered an interest. Per-volume instances of filter drivers register with a filter manager for pre-callbacks (for I/O to the file system) and post-callbacks (for I/O from the file system), and identify which I/O requests (e.g., create, read, write) they are registering to receive callbacks. The filter manager orders the instances for callbacks. When an I/O request is received, the filter manager converts the I/O request to callback data and calls the interested filters in the callback order, whereby the filter instances can process the I/O data. As the request returns from the file system, filters desiring post callbacks are called in the reverse order. Efficient context management for the filters and other functions, such as non-reentrant file I/O, are also provided by the model.

Abstract: Described is a method and system that manages filenames for filter drivers in a file system. The present invention includes a filter manager that handles filename queries from the filter drivers. The filter manager returns a pointer to the requesting filter driver that points to a filename information structure corresponding to the type of filename requested. The filter manager also manages a cache of filename information structures that include information that can be shared among the various filter drivers, amortizing the filename queries for filter drivers. The caching functionality of the filter manager increases the efficiency and reduces the overhead of filename queries within the file system by reducing the number of filename operations required for a file system filter driver to retrieve a desired portion of the filename.

Abstract: A method and system for ordering software modules in a guaranteed order for execution. Unique values are statically assigned to software modules (e.g., filter drivers) when fully developed. Each module's assigned value determines its relative position to other modules in a stack or other arrangement, fixing the execution order for any set of filter drivers. Static values may comprise floating-point numbers, whereby each new software module may be assigned a number that enables positioning it between any two existing software modules. For example, filter drivers may be generally classified and assigned values in a range according to type. Drivers of the same type may be ordered within their general range to guarantee one possible ordering. A filter manager architecture is described, in which filter drivers register with a manager for relevant file system I/O operations. The manager calls appropriately registered filter drivers in an order based on their assigned numbers.