Patent Grant
7552223
Embodiments of the present invention relate generally to computer networks. More particularly, embodiments of the present invention relate generally to file systems and storage devices.
Large organizations are geographically distributed. They may have a few large central sites that have high-speed local area networks (LANs) where local data can be consolidated into a central area or system. However, large organizations may also have smaller remote offices, branch offices, or/and other edge locations that have lower bandwidth and higher latency connectivity to the centralized data repositories. The edge locations may not have information technology (IT) staffs to service local data needs such as, for example, backing up the servers or replacing failing hardware and/or software. Users at remote offices can typically see much poorer performance, reliability, and services from the corporate IT infrastructure than their counterparts at a central site.
Sharing data across large sites is also cumbersome. These sites are usually connected by dedicated high bandwidth links. However, the geographical distances between sites impose latencies that are unacceptable for many applications.
The current solution is to provide a file server (such as a filer from Network Appliance, Inc.) at each edge location and automatically back up the server to a central location over the wide area network (WAN). Read-only data that is shared across sites can be replicated by using asynchronous mirroring. Hypertext Transfer Protocol (HTTP) and streaming traffic can be cached using a network cache such as, for example, the NetCache appliance from Network Appliance, Inc.
Managing file servers at edge locations can be expensive in terms of cost and/or resource. The task of backing up data across WANs requires careful planning and administration. Replicating read-only volumes across WANs is often an overkill. In many cases, only a small percentage of the volume is actually used on a regular basis (e.g., /usr/local/bin). Typically, dynamic data sets (e.g., home directories of a user) cannot be replicated and must be managed independently at each location.
Therefore, the above-described products and approaches are limited to particular capabilities and features and suffer from a number of constraints.
In one embodiment of the invention, a method to provide data consistency in a storage system, includes: providing, by a server to a proxy cache, a lock associated with a delegated file in the server; in response to a write request from a client, modifying data in a cached copy of the delegated file in the proxy cache; revoking, by the server, the lock associated with the delegated file, in response to a request from another device to access the delegated file so that the delegated file is now a formerly delegated file; and writing the modified data to the formerly delegated file in the server to update the formerly delegated file; and permitting access to the formerly delegated file by the another device.
In another embodiment, a method to provide data consistency in a storage system, includes: providing, by a server to a proxy cache, a lock associated with a delegated file in the server; in response to a write request from a client, modifying data in a cached copy of the delegated file in the proxy cache; and writing the modified data to the delegated file in the server to update the delegated file.
In another embodiment, a method to provide data consistency in a storage system, includes: receiving a first request for transmission to a server, in order to access an object; receiving a second request for transmission to the server, in order to access the object; wherein a first version of the object in response to the first request includes a last recorded change (LRC) time value and wherein the second request has a request (RST) time value that indicates when the second request was made; and if a time difference is greater than a pre-selected time value for which the LRC time value for the first version of object is greater than the RST time value when the second request was made by the pre-selected time, then verifying, by the proxy cache, the object in the server.
These and other features of an embodiment of the present invention will be readily apparent to persons of ordinary skill in the art upon reading the entirety of this disclosure, which includes the accompanying drawings and claims.
Embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment of the invention can be practiced without one or more of the specific details, or with other apparatus, systems, methods, components, materials, parts, and/or the like. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of embodiments the invention.
The above-variables n and m may be any suitable integer value. Thus, the number of client devices (generally referred herein as client(s) 105) and the number of servers (generally referred herein as server(s) 110) may vary. For example, the network 100 may be implemented with only one client device 105 and/or with only one server 110. The client devices 105 may be coupled via local area network (LAN) 120 to the proxy cache 115, while the servers 110 may be coupled via wide area network (WAN) 125 to the proxy cache 115.
The forward proxy configuration in
In an embodiment, the proxy cache 115 and client devices 105 can communicate with each other via LAN 120 by use of an open standard protocol 130, such as the Network File System (NFS) protocol. As described below, the open standard protocol 130 may also be other suitable open standard protocols such as the Common Internet File System (CIFS) protocol. The proxy cache 115 and servers 110 can communicate with each other via Wide Area Network (WAN) 125 by use of an open standard protocol 135, such as NFS. By use of an open standard protocol along the WAN 125 and LAN 120, the special software required in conventional approaches is advantageously avoided in an embodiment of the invention. In particular, the clients 105 can now be heterogeneous by use of an open standard protocol such as NFS. In other words, the term heterogeneous clients means that clients from different manufacturers or vendors can be advantageously used. The clients will not require specialized software in order to communicate with the servers 110.
Additionally, the open standard protocol avoids configuration changes that would otherwise be required for the client devices 105 when the proxy cache 115 is installed in the network 100. Thus, a proxy cache 115 permits low overhead and cost with respect to network administration. Also, the proxy cache 115 may be administered or installed from a location remote from a server 110 or a client 105 in the network 100.
Typically, the proxy cache 115 can identify the servers 110 and clients 105 that are coupled to the proxy cache 115 and the particular data files that are in the servers 110.
As an example, if a client 105 requests data and the data is not in the proxy cache 115, then a “cache miss” would occur. On the other hand, if the requested data is in the proxy cache 115, then a “cache hit” would occur. These operations are described in detail below with reference to
In the event of a cache hit, the proxy cache 115 will transmit the requested data to the requesting client 105. In the event of a cache miss, the proxy cache 115 will request the data from a server 110 and then provide the data to the requesting client 105. The data from the server 110 will be cached as an active data set 140 in the proxy cache 115 and is immediately available to the other clients 105. An active data set is an attribute of clients and their applications, and is cached data with reference for a given time period (or window of time). Thus, the active data set can differ depending on the given time period (e.g., an active data set for a given time period of 2 minutes may differ for an active data set for a given time period of 1 day or 1 week).
The proxy cache 115 permits collaborative sharing of cached copies of data among the clients 105. The collaborative sharing situation assumes that a particular data requested from the server 110 by a client 105 will also be likely requested by at least another client 105.
In an embodiment, the proxy cache 115 will cache an active data set 140, which is a set of recently requested or frequently requested data that has not been flushed from the proxy cache 115. The active data set 140 will be a subset of the data stored in the server(s) 110. When a client device 105 sends a read request 145 in order to read a particular copy 150 of a data file from a server 110, the read request 145 is received by the proxy cache 115 which checks if the particular part (e.g., data block) of that file or folder is cached locally in the proxy cache 115. If the requested particular data file is in the active data set 140, then a cache hit condition occurs, and the proxy cache 115 will transmit the requested data via LAN 120 to the requesting client device 105.
On the other hand, if a data block in the requested file is not stored as part of the active data set, then a cache miss condition occurs. As a result, the proxy cache 115 will send a request 155 to a server 110 to provide a copy of the missing data block in the requested data file.
In an embodiment, the cached file remains as part of the active data set 140, until the file is replaced in the active data set 140 by a suitable replacement strategy (such as, for example, a first-in-first-out management of data or the least recently used, LRU, algorithm). Of course, as described below, other data replacement strategies may be used with respect to management of the active data set 140, in an embodiment of the invention. For example, a file may be designated for permanent storage until a user of the client 105 issues a command to delete (flush) the file from the active data set 140.
The network interface 161 includes components for receiving storage-related service requests from a client 105.
Generally, a file system can logically organize information as a hierarchical structure of directories and files on the storage devices (e.g., disks). Each file (on the disks) may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially-formatted file in which information about other files and directories are stored.
The storage device manager 170 manages the storage devices 171 in a storage system. The storage device manager 170 receives read and write commands from the file system 169 and processes the commands by accordingly accessing the storage system. The storage device manager 170 takes a block's logical address from the file system 169 and translates that logical address to a physical address in one or more storage devices 171 in storage system. In one embodiment, the storage device manager 170 manages storage devices in accordance with RAID (Redundant Array of Independent, or Inexpensive, Disks).
Generally, disk storage is typically implemented as one or more storage “volumes” that is formed by physical storage disks, defining an overall logical arrangement of storage space. Each volume is typically associated with its own file system, and the terms, volume and file system, will generally be used synonymously. The disks within a volume may be typically organized as one or more groups of RAID.
The functions for the other modules shown in
Cache Hit
Reference is now made to the block diagrams in
Assume that a read request 172 is received by the proxy cache 115 (
Based on the unique name 182, the file system layer 169 will perform a lookup function in order to obtain a local cache file ID 183. In an embodiment, a module 184 in the file system 169 can perform this lookup function. If there is no matching local cache file ID, then a cache miss occurs, which is described further below.
The local cache file ID 183 is an index into an inode file 185 that points to an appropriate inode record 186. The inode record for an inode file 105 contains information describing the inode file associated with a given file system. Generally, an inode record is a data structure used to store information, such as metadata (attributes), about a file, whereas the file data blocks are structures used to store the actual data for the file. The information contained in an inode record may include, e.g., ownership of the file, access permission for the file, size of the file, file type and references to locations on disk of the data blocks for the file. The inode record 186 for the inode file 185 contains a pointer to a file system data block (e.g., WAFL data block), generally referenced as 188. A file data block is defined as a minimum addressable amount of data handled by the file system. A file data block is capable of storing, for example, 4 kilobytes (KB) of data. The inode record 186 can also point to indirect blocks which in turn can point to other file data blocks or other indirect blocks. For example, the indirect block 188d points to blocks 189a, 189b, and 189c, each of which may be file data blocks or indirect blocks.
In particular, the inode numbers 187 in an inode record 186 points to the file data blocks or indirect blocks. It is also noted that an inode record 186 also includes attributes 190 of a file stored locally in the proxy cache 115. It is further noted that in one embodiment, the local cache file ID 183 is also an index into a second inode file 192 that points to an appropriate inode record 193 that contains server-side attributes for a file. Server-side attributes can include, for example, file system ID, file ID, block size, number of hard links, and space available on the file system. Of course, the second inode file 192 can be combined with the inode file 185. By creating the second inode file 192, the first inode file 185 will advantageously not require modification to perform some of the functions described with reference to
It is also noted that an inode record includes a file buffer tree which is a data structure used to represent a file on a disk in a file system. In
An iovector 194 is then formed, where the iovector is a list of block numbers 187 in the file buffer tree 191. A block number 187 will indicate if a file data block is present or absent for a particular file. In an embodiment, a module 195 can form the iovector 194 and determine the presence or absence of a file data block. In an embodiment, a block number 187 will have a special value X (where X can be, e.g., −1 or −3) as shown by block number 187a, where the special value X indicates that the local cache file stored in the proxy cache 115 does not have a requested data block.
In a cache hit condition, a block number will not have the special value X, and the iovector is sent to the storage device manager 170 (e.g., a RAID layer). The storage device manager 170 will provide a pointer to the appropriate storage device(s) 171 and send the requested data block to the file system and to the NFS service (in the case of an NFS request) which creates an NFS response 173 to the requesting client 105. The requesting client 105 can, therefore, receive the requested file. The method described above can also be used to process requests for directories.
The special value X in the list of block numbers permits the tracking of buffers (in the storage devices) in the proxy cache with missing data blocks for a requested file and thus permits the tracking of sparse data. The level of indirection (by calculation of the unique name 182) permits a file handle to point to a different slot in the inode file, depending on the particular time, since a data block or cache file may be flushed from the proxy cache 115.
Cache Miss
When the iovector 194 is constructed, and if a block number 187 in the file buffer tree 191 contains the special value X indicating that the requested file data block is absent from a buffer (in the storage devices 171), then a cache miss condition is triggered. Alternatively, a cache miss condition is triggered if a matching file ID 183 is not found by the file system 169 when performing the table lookup function after computing the unique name 182.
The NFS fill engine 166 for an NFS request 196 (or CIFS fill engine for a CIFS request) will request the absent file data block from the server 110 with the data block. In the example of
When the file data block is fetched (197) by the NFS fill engine 166 from the server 110, the data block is filled into the storage disk 171 by the remote fills layer 168, file system 169, and storage device manager 170. The block numbers in the buffer tree 191 is then updated and a file data block is allocated. The file data blocks are then sent to the requesting client 105 so that the requested file is provided to the client. The method described above can also be used to process requests for directories.
It is further noted that the embodiment shown in
Typically, when a client 105 sends a request in the NFS protocol, a separate request is made for each data block. It is also noted that a separate request in the CIFS protocol is made for each data block. As an example, assume that a first client 105 (e.g., client 105(1) in
As an example of a cache miss condition, assume that a second client 105 (e.g., client 105(2) in
Assume as a further example that another client 105 (e.g., client 105(n) in
Thus, replication of a partial object occurs in the proxy cache 115 in response to a client request, where a partial object is defined as one or more blocks of data of a file. In the example above, the data block 188c was replicated in the proxy cache 115 in response to a client request and is subsequently available to other requesting clients 105. As discussed below, suitable data replacement policies may be used to flush (from the proxy cache 115) a data block 188 or a file defined by multiple data blocks 188. In contrast, currently known replication techniques replicate entire files (e.g., entire volumes or entire sets of files are replicated in various mirroring techniques).
Replacement Policies
Various methods may be used as a replacement policy to refresh, retain, or flush data files in the active data set 140 from the proxy cache 114.
Alternatively or additionally, a file in the active data set 150 may be locked (310) by a user by sending a lock command to the proxy cache 115 from a client 105, so that the lock command prevents the file from being deleted in the proxy cache. The user may send a lock command if, for example, the user is concerned that the link connection to a server 110 may be broken or that the server 110 may fail. Alternatively, an attribute (metadata) of an object (e.g., file or data block of a file) may indicate how long an object is to remain cached in the proxy cache.
Alternatively or additionally, the user may provide (315) hints or indicators to the proxy cache 115 to designate particular cached files as important. As a result, the indicators will prevent the designated important files from being flushed from the storage unit(s) of the proxy cache 115.
By use of the proxy cache 115, data can be distributed and replicated at various remote locations and advantageously avoid the use of conventional mirroring techniques to replicate data. The use of conventional mirroring techniques requires that entire data sets are mirrored at a pre-determined time or interval (e.g., on a nightly basis) and requires disk spaces for the entire data sets. In contrast, the proxy cache caches 115 replicates data in the active data set 140 on-demand, and the active data set 140 advantageously eliminates the large disk requirements of previous methods for data replication. Additionally, the active data set 140 is automatically updated or flushed in response to a cache miss, and thus eliminates the special software requirements of previous methods for data replication.
Method of Consolidating the Mount Points and Re-Writing/Mutation of File Handles)
In order to perform operations via the NFS network file system protocol, a client sends NFS requests to the NFS server with: (1) an NFS file handle that specifies the target of the operation, (2) the operation (lookup, read, write, change permissions), and (3) the user on whose behalf the request is sent. When an NFS client wants to access a remote file system for the first time, the client first needs to obtain a root file handle, which is the file handle for an entry point into a volume (as noted above, the term “volume” is synonymous with the term “file system”). To this end, the client host sends a mount request to the server's mount daemon, where the mount request is part of the protocol for accessing a root file handle and a daemon is a program that runs continuously and exists for the purpose of handling periodic service requests that a computer system expects to receive. The daemon program forwards the requests to other programs (or processes) as appropriate. The server's mount daemon verifies that the client has permission to access the requested file system. When the mount daemon grants access, it sends a (directory) file handle back to the NFS client. Typically, the file handles are each, for example, 32 bytes of opaque identifier data. If a file name is changed, the file handle remains the same for that renamed file. Thus, the mounting process described above is a protocol to access a root file handle.
NFS file handles are not globally/universally unique, since two different servers could use the same file handles. Traditionally, this condition is not a problem, as clients keep track of which file handles are associated with each particular server. When a proxy cache 115 is used to consolidate mount points, it may export volumes from many different servers. Since these file handles are not unique, the proxy cache 115 may be unable to determine which file handle corresponds to which origin server, and this condition may result in a collision problem, since a first file in a first specific server and a second file in a second specific server may have identical file handles. The problem is exacerbated since the file handle is defined to be opaque, which means that typically the content of a file handle can not be determined and only the name of the file handle can be obtained.
In an embodiment of the invention, by mutating file handles before sending the file handles to the client 105, the proxy cache 115 is able to interpret file handles and determine the destination server 105 of any file handle. As a result, clients 105 can access data through a proxy cache 115 without an explicit knowledge of the particular server at which the data originates.
As shown in
An embodiment of the invention allows for the virtualization of server-side file handles. By introducing a proxy cache 115 between clients 105 and servers 110, file handles can be mutated (translated) to allow for the construction of a uniform global name-space. File handles returned to clients can be changed to indicate that they map to different origin servers, different sets of export options, or that they cross mount points. By adding a layer of indirection between the file handle sent to a client and the file handle used to access the object on the origin server, changes to origin servers 110 can made without ever impacting the clients 105.
As shown in
A translation table 605 contains hash values N (e.g., N1, N2, N3, . . . ), while an FSid table 610 contains FSid values for each volumes in the servers 110. When traffic 615 is received from a server 110 with a particular FSid value in the file handle (e.g., volume 505 in server 110(1) with FSid=VALUE1 in the example of
A value N in table 600 is computed based on some hash that is based on the address of the server 110 with the volume and/or other identifiers. The hash for each N value is unique and thus avoids the name collision problem that was mentioned above. Typically, a value N may be an 8 byte number and may have a value set based on the server name, volume name and file name (e.g., filer1/Vol0/file0).
Alternatively, a value N may be calculated based on the server Internet Protocol (IP) address and the server file handle value by use of the MD5 algorithm as previously described above. Since the file handle value may not be unique across different servers, the server IP address can make each value of N distinct for files across different servers.
As shown in
Additionally or alternatively, since the mapping 600 can be duplicated into multiple proxy caches, a proxy cache (e.g., proxy cache 115) can be swapped with a new or another proxy cache (e.g., proxy cache 705) without requiring clients 105 to un-mount and re-mount their volumes and without requiring other changes in the clients 105.
Method of Creating and Using a Virtual Global Name Space
In addition to allowing for the consolidation of mount points as described above, an embodiment of the invention also provides for the creation of a uniform global name-space. Traditionally, NFS mount points can not be nested (i.e., if a client mounts an NFS volume, then that volume can not contain other mount points). This limitation makes the creation of a uniform view of a network very difficult.
Using virtualization of file handles in accordance with an embodiment of the invention, administrators can configure arbitrary directories in NFS exported volumes as mount points (access points to a file system). This means that clients 105 only need to mount one volume, but when they access this volume, the proxy cache will properly redirect the client requests to the particular appropriate volume. Thus, a proxy cache 115 can inform every client 105 about each server 110 (or new added server) by use of a single mount point. By renaming objects, a virtual global view of the files (i.e., virtual global name space) is created, and as a result, each client 105 has information about each server 110 and about each file in each server 110 by use of the virtual global view of the files. The virtual global name space leads to ease in administration of the clients 105.
As shown in
An advantage permitted by the single mount point is that the clients 105 need not be aware of every single mount points. In previous approaches, each client typically has an FStab file (file system table file), which lists all known remote file systems in folders (i.e., FStab is a list of local directories or folders in a client where the client can access a driver and server name and volume name). If a change occurs in a server 110, where the change affects the name space, then each client 105 will be required to be reconfigured so that the clients are able to access the servers, resulting in the complicated and time consuming mount point management tasks of the previous approaches.
In an embodiment of the invention, each client will only need to mount the directory 805 and this single consolidated mount point leads to simplified mount point management. In particular, the mount point is un-mounted and mounted on the proxy cache 115, and as a result, the volume name 805 will not require un-mounting and re-mounting on the clients 105. Thus, the directory 805 provides the function of a file system table file where clients can access drivers and servers. The directory 805 provides a list of access points to remote file systems and associated attributes as stored in a remote server(s) 110.
Method of Creating Multiple Mount Points where a Set of Attributes are Associated with a Mount Point.
A file handle can be re-written in different ways for the same object. In an embodiment, a file handle can be re-written in different ways based upon attributes of the associated local mount point on the proxy cache.
Reference is now made to
A local volume name can have associated attributes or meta-data such as access restrictions, eligibility for storage or cachebility, security attributes, authentication, and authorization levels for proxy cache devices, as well as read-only or write-only attributes for servers. The attribute associated with the same data can be changed by accessing a mount point associated with another volume that shares the same data. Thus, particular attributes can be associated with a particular mount point or access point, which can be hashed to form a unique identifier. In an embodiment of the invention, the unique identifier is a hashing of a local volume name, file system ID, and server IP address by use of a suitable hashing algorithm such as MD5. In the example of
It is further noted that the same physical object on disk in the proxy cache 115 can be accessed from the different mount points.
The lock 920 for the particular file 910 is typically granted by the server 110 if the particular file 910 is not being accessed on the server 110 by another proxy cache or another client, or if no other conflicting access is occurring for the file 910. The lock 920 will typically specify the object of the delegation. In the example of
After the lock 920 for the particular file 910 is granted, the write request 905 from the client 105(1) to the particular (delegated) file 910 will result in modification of the cached copy 910′ of the delegated file 910 that is cached in the proxy cache 115. The modification of the cached copy 910′ is shown by modified data 930. The processing of write requests and read requests for a file that is cached in the proxy cache 115 has been previously discussed above with reference to
An involuntary giveback of the lock 920 from the proxy cache 115 to the server 110 for the delegated file 910 will occur if another client (client 105(n) in this example) sends a write request or read request (request 935 in this example) to the server 110 to access the delegated file 910 that is stored in the server 110. An access request from another proxy cache for the delegated file 910 may also results the involuntary giveback of the lock 920 from the proxy cache 115 to the server 110. The server 110 will send a lock recall 925 to revoke the lock 920 held by the proxy cache 115 for the delegated file 910. In response to the lock recall 925, the proxy cache 115 will involuntarily give back the lock 920 to the server 110 for the delegated file 110. Additionally, in response to the lock recall 920, the proxy cache 115 will also send (to the server 110) the modified data 930 of the cached copy 910′ of the delegated file 910 to the server, where the modified data 930 includes all changes that has been performed by the write request(s) 905 from the client 105(1) for the delegated file 910. The proxy cache processor and the cache operating system (
After the server 110 receives the modified data 930, the server 110 can update the delegated file 910 based upon the previous write request(s) 905 that were received by the proxy cache 115 from the client 105(1). As a result, the server 110 has the latest (most fresh) version of the particular file 910 and can serve this latest version to the requesting client 105(n) and any proxy cache or client that subsequently request access to the file 910.
After the proxy cache 115 gives back the lock 920 to the server 110, the proxy cache 115 sends the modified data 930 by asynchronously writing the modified data 930 to the server 110. The proxy cache 110 can asynchronously write the modified data 930 to the server by a delayed write method and/or by a deferred write method.
In the delayed write method, the proxy cache 115 can write the modified data 930 to the server 115 as soon as the proxy cache is able to perform a write operation 1010 to the server 110. For example, the write operation 1010 can be performed during idle times in the network, and/or based upon bandwidth limitations (e.g., perform the write operation during a time when there is maximum network bandwidth available).
In the deferred write method, the proxy cache 115 can write the modified data 930 to the server 110 by performing the write operation 1010 by periodically performing the write operation or by performing the write operation according to a schedule.
The write operation 1010 can be performed as a background operation of the proxy cache 115 or can be performed at a later time.
The embodiment shown in
The write operation 1010 can be performed at a rate slower than the rate of write operation 1005. Additionally or alternatively, the write operation 1010 can be performed at a delayed time or at a time subsequent to the write operation 1005. Thus, if the WAN connecting the proxy cache 115 and server 110 fails or if a planned-disconnect occurs between the proxy cache 115 and server 110, or if the server 110 becomes non-operational, then the proxy cache 115 can perform the write operation 1010 to the server 110 at a later time when the WAN becomes operational. This delayed write feature insures that the write data is eventually stored in the server 110, without slowing down or affecting the operation of the client 105.
The write operation 1005 may be permitted to invalidate non-read-only data stored in the proxy cache 115. Additionally, write data (from write operation 1005) that is cached in the proxy cache 115 does not require a deletion action, since the write data will be subsequently flushed from the proxy cache 115 by use of, for example, a FIFO operation as described above.
Delta Writes
Assume that the client 105(1) (or another device) sends a write request 1120 to modify a cached file 1125 in the proxy cache 115, where the modification is shown as modified data 1130. If the proxy cache 115 has not yet performed a write operation 1105 to write the modified data 1130 to memory in server 110, then the tag module 1110 will not place a tag 1115. Since a tag 1115 is not yet placed on the modified data, the proxy cache operating system (
Data Consistency
However, in the example of
As shown in
In an embodiment of the invention, the proxy cache 115 (by use of cache operating system 1211) can read the RST value 1373 and LRC value 1374 in the hash table 1370 for a cached object. If the file system 169 determines that the time difference 1390 (
If the time difference 1390 is not greater than the pre-determined time value of, e.g. 30 seconds, then the proxy cache 115 can serve the object 1210a to the requesting client.
The above method permits data consistency to be achieved for data that is stored in the proxy cache. It is further noted that the hash table 1370 may be cleaned up periodically by the file system 169.
The various engines or modules discussed herein may also be, for example, software, commands, data files, programs, code, modules, instructions, or the like, and may also include suitable mechanisms.
Reference throughout this specification to “one embodiment”, “an embodiment”, or “a specific embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment”, “in an embodiment”, or “in a specific embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Other variations and modifications of the above-described embodiments and methods are possible in light of the foregoing teaching. Further, at least some of the components of an embodiment of the invention may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, or field programmable gate arrays, or by using a network of interconnected components and circuits. Connections may be wired, wireless, by modem, and the like.
It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application.
It is also within the scope of the present invention to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above.
Additionally, the signal arrows in the drawings/Figures are considered as exemplary and are not limiting, unless otherwise specifically noted. Furthermore, the term “or” as used in this disclosure is generally intended to mean “and/or” unless otherwise indicated. Combinations of components or steps will also be considered as being noted, where terminology is foreseen as rendering the ability to separate or combine is unclear.
As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
Aspects of the invention may also be implemented in hardware, software, firmware, and/or a combination of any of hardware, software, or firmware.
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
This application is a continuation-in-part of and claims the benefit of U.S. patent application Ser. No. 10/245,798, by Emmanuel Ackaouy et al., filed Sep. 16, 2002, now U.S. Pat. No. 7,284,030, and entitled “APPARATUS AND METHOD FOR PROCESSING DATA IN A NETWORK”. Application Ser. No. 10/245,798, now Pat. No. 7,248,030 is hereby fully incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5535375 | Eshel et al. | Jul 1996 | A |
| 5864852 | Luotonen | Jan 1999 | A |
| 5893140 | Vahalia et al. | Apr 1999 | A |
| 5907678 | Housel, III et al. | May 1999 | A |
| 5924116 | Aggarwal et al. | Jul 1999 | A |
| 5946685 | Cramer et al. | Aug 1999 | A |
| 5946690 | Pitts | Aug 1999 | A |
| 5950205 | Aviani, Jr. | Sep 1999 | A |
| 5987506 | Carter et al. | Nov 1999 | A |
| 5991810 | Shapiro et al. | Nov 1999 | A |
| 6065058 | Hailpern et al. | May 2000 | A |
| 6085193 | Malkin et al. | Jul 2000 | A |
| 6085234 | Pitts et al. | Jul 2000 | A |
| 6128623 | Mattis et al. | Oct 2000 | A |
| 6167446 | Lister et al. | Dec 2000 | A |
| 6178461 | Chan et al. | Jan 2001 | B1 |
| 6182111 | Inohara et al. | Jan 2001 | B1 |
| 6230160 | Chan et al. | May 2001 | B1 |
| 6237060 | Shilts et al. | May 2001 | B1 |
| 6282580 | Chang | Aug 2001 | B1 |
| 6292835 | Huang et al. | Sep 2001 | B1 |
| 6311216 | Smith et al. | Oct 2001 | B1 |
| 6370620 | Wu et al. | Apr 2002 | B1 |
| 6438652 | Jordan et al. | Aug 2002 | B1 |
| 6442651 | Crow et al. | Aug 2002 | B2 |
| 6463508 | Wolf et al. | Oct 2002 | B1 |
| 6505241 | Pitts | Jan 2003 | B2 |
| 6542964 | Scharber | Apr 2003 | B1 |
| 6553411 | Dias et al. | Apr 2003 | B1 |
| 6578113 | Krishnamurthy et al. | Jun 2003 | B2 |
| 6598121 | Challenger et al. | Jul 2003 | B2 |
| 6643672 | Lebel | Nov 2003 | B1 |
| 6658462 | Dutta | Dec 2003 | B1 |
| 6658463 | Dillon et al. | Dec 2003 | B1 |
| 6665705 | Daniels-Barnes et al. | Dec 2003 | B1 |
| 6675214 | Stewart et al. | Jan 2004 | B2 |
| 6741970 | Smith et al. | May 2004 | B2 |
| 6751608 | Cohen et al. | Jun 2004 | B1 |
| 6801927 | Smith et al. | Oct 2004 | B1 |
| 6823377 | Wu et al. | Nov 2004 | B1 |
| 6886077 | Cuomo et al. | Apr 2005 | B2 |
| 6907501 | Tariq et al. | Jun 2005 | B2 |
| 6952736 | Westbrook | Oct 2005 | B1 |
| 7003630 | Kissell | Feb 2006 | B1 |
| 7103794 | Malcolm et al. | Sep 2006 | B2 |
| 7159013 | Cudd et al. | Jan 2007 | B2 |
| 20010000083 | Crow et al. | Mar 2001 | A1 |
| 20020004846 | Garcia-Luna-Aceves | Jan 2002 | A1 |
| 20020004917 | Malcolm et al. | Jan 2002 | A1 |
| 20020026511 | Garcia-Luna-Aceves | Feb 2002 | A1 |
| 20020026560 | Jordan et al. | Feb 2002 | A1 |
| 20020046266 | Muralidhar et al. | Apr 2002 | A1 |
| 20020118835 | Uemura | Aug 2002 | A1 |
| 20030004998 | Datta | Jan 2003 | A1 |
| 20030065874 | Marron et al. | Apr 2003 | A1 |
| 20030120867 | Cuomo et al. | Jun 2003 | A1 |
| 20030145112 | Keller et al. | Jul 2003 | A1 |
| 20030149737 | Lambert et al. | Aug 2003 | A1 |
| 20030163731 | Wigley et al. | Aug 2003 | A1 |
| 20030172145 | Nguyen | Sep 2003 | A1 |
| 20030233423 | Dilley et al. | Dec 2003 | A1 |
| 20040044740 | Cudd et al. | Mar 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| WO 0235799 | May 2002 | WO |
| WO 0242874 | May 2002 | WO |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10245798 | Sep 2002 | US |
| Child | 10423477 | US |
