Methods for accessing data in a compressed file system and devices thereof

Information

  • Patent Grant
  • 9020912
  • Patent Number
    9,020,912
  • Date Filed
    Monday, February 20, 2012
    12 years ago
  • Date Issued
    Tuesday, April 28, 2015
    9 years ago
Abstract
A method, computer readable medium, and network traffic management apparatus that accesses data in a compressed file system includes obtaining an original write request from a client computing device including at least object data. The object data is compressed into a plurality of compressed blocks. A mapping of each compressed block to a portion of the object data compressed therein is generated, wherein the portion of the object data compressed therein is represented in the mapping by a unique object identifier, a start offset, and a length. The compressed blocks and the mapping are stored in at least one data storage device. At least one data access request for at least a portion of the object data is serviced based on the mapping.
Description
FIELD

This technology generally relates to accessing object data in a compressed file system, and, more particularly, to efficient methods and devices for servicing read and write data access requests independent of protocol.


BACKGROUND

In order to optimize utilization of relatively fast storage devices having limited capacity, such as in a tiered file storage system, relatively infrequently accessed files are often compressed into blocks of data and archived in relatively slow storage devices of the tiered storage system. Accessing an archived file, such as in response to a read or write request, generally requires decompressing the entire file, as identified based on a file handle or other identifier included in the request, in order to locate a portion of the file identified by a start offset and/or a length included in the request.


Accordingly, although such read and write requests often identify only a portion of the original file, all of the compressed blocks associated with the original file must be retrieved and decompressed in order to locate the requested portion, in order to service a read request, or locate the portion to be written, in order to service a write request. Additionally, in order to service a write request, the entire original file generally must be recompressed, subsequent to the write procedure, even though only a portion of the original file may have been modified. Retrieving and decompressing all of the compressed blocks associated with a file, and in the case of a write request, recompressing an entire file, requires significant time and resources thereby increasing the response time to the requesting client computing device, which is undesirable.


SUMMARY

A method for managing requests for content includes obtaining with a network traffic management apparatus an original write request from a client computing device including at least object data. The object data is compressed with the network traffic management apparatus into a plurality of compressed blocks. A mapping of each compressed block to a portion of the object data compressed therein is generated with the network traffic management apparatus, wherein the portion of the object data compressed therein is represented in the mapping by a unique object identifier, a start offset, and a length. The compressed blocks and the mapping are stored with the network traffic management apparatus in at least one data storage device. At least one data access request for at least a portion of the object data is serviced with the network traffic management based on the mapping.


A non-transitory computer readable medium having stored thereon instructions for managing requests for content comprising machine executable code which when executed by at least one processor, causes the processor to perform steps including obtaining an original write request from a client computing device including at least object data. The object data is compressed into a plurality of compressed blocks. A mapping of each compressed block to a portion of the object data compressed therein is generated, wherein the portion of the object data compressed therein is represented in the mapping by a unique object identifier, a start offset, and a length. The compressed blocks and the mapping are stored in at least one data storage device. At least one data access request for at least a portion of the object data is serviced based on the mapping.


A network traffic management apparatus includes a memory, configurable logic, and a processor coupled to the memory and the configurable logic, at least one of the configurable logic configured to implement or the processor configured to execute programmed instructions stored in the memory including obtaining an original write request from a client computing device including at least object data. The object data is compressed into a plurality of compressed blocks. A mapping of each compressed block to a portion of the object data compressed therein is generated, wherein the portion of the object data compressed therein is represented in the mapping by a unique object identifier, a start offset, and a length. The compressed blocks and the mapping are stored in at least one data storage device. At least one data access request for at least a portion of the object data is serviced based on the mapping.


This technology provides a number of advantages including methods, non-transitory computer readable medium, and devices that efficiently access data in a compressed file system, the data being required to service read or write data access requests received from networked client computing devices. With this technology, a mapping of object data to compressed blocks including compressed object data is stored and utilized to retrieve only a portion of the compressed blocks storing the object data required to service a read or write request. Accordingly, only a subset of the compressed blocks storing object data needs to be decompressed to service a read request for only a portion of a file. Additionally, only a subset of the compressed blocks storing object data needs to be decompressed, modified, and rewritten to service a write request that does not require additional storage space beyond the fixed size of the compressed blocks. As a result, resource utilization is improved as well as response time, thereby improving the user experience with the file storage system.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a block diagram of a network environment with an exemplary network traffic management apparatus that accesses data in a compressed file system;



FIG. 2 is a flowchart of an exemplary method for servicing read data access requests in a compressed file system; and



FIG. 3 is a flowchart of an exemplary method for servicing write data access requests in a compressed file system.





DETAILED DESCRIPTION

A network environment 10 with an exemplary network traffic management apparatus 14 for accessing data in a compressed file system is illustrated in FIG. 1. In this example, the environment 10 includes client computing devices 12, network traffic management apparatus 14, and servers 16, which are coupled together by local area networks (LAN) 28 and wide area network (WAN) 30, although other types and numbers of devices, components, and elements in other topologies could be used. While not shown, the environment 10 also may include additional network components, such as routers, switches and other devices, which are well known to those of ordinary skill in the art and thus will not be described here. This technology provides a number of advantages including methods, non-transitory computer readable medium, and apparatus that efficiently service data access requests in a compressed file storage system.


In this example, the network traffic management apparatus 14 is coupled to client computing devices 12 through one of the LANs 28, although the client computing devices 12, or other devices, and network traffic management apparatus 14 may be coupled together via other topologies. Additionally, the network traffic management apparatus 14 is coupled to the servers 16 through another one of the LANs 28, although the servers 16, or other devices, and the network traffic management apparatus 14 may be coupled together via other topologies. LANs 28 each may employ any suitable interface mechanisms and network communication technologies including, for example, teletraffic in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Ethernet-based Packet Data Networks (PDNs), combinations thereof, and the like. The network traffic management apparatus 14 is further coupled to client computing devices 12 through WAN 30, which may comprise any wide area network (e.g., Internet), although any other type of traffic network topology may be used. Various network processing applications, such as CIFS applications, NFS applications, HTTP Web Server applications, and/or FTP applications, may be operating on servers 16 and transmitting data (e.g., files, Web pages) through the network traffic management apparatus 14 in response to requests for content from client computing devices 12.


The network traffic management apparatus 14 facilitates servicing of data access requests in a compressed file storage system as illustrated and described with the examples herein, although network traffic management apparatus 14 may perform other types and numbers of functions, such as optimizing, securing and accelerating the traffic between client computing devices 12 and servers 16, and/or one or more applications. Network traffic management apparatus 14 includes at least one processor 18, memory 20, optional configurable logic device 21, I/O interface 22, and interface device 24 which are coupled together by bus 26, although network traffic management apparatus 14 may comprise other types and numbers of elements in other configurations. Although network traffic management apparatus 14 is shown in this example as being a standalone device, such as a BIG-IP® device offered by F5 Networks, Inc., of Seattle, Wash., it should be appreciated that the network traffic management apparatus 14 could also be one of several blades servers coupled to a chassis device, such as a VIPRION® device, also offered by F5 Networks, Inc., of Seattle, Wash.


Processor(s) 18 may execute one or more computer-executable instructions stored in the memory 20 for the methods illustrated and described with reference to the examples, although the processor(s) can execute other types and numbers of instructions and perform other types and numbers of operations. The processor(s) 18 may comprise one or more central processing units (CPUs) or general purpose processors with one or more processing cores, such as AMD® processor(s), although other types of processor(s) could be used (e.g., Intel®).


Memory 20 may comprise one or more tangible storage media and/or devices, such as RAM, ROM, flash memory, CD-ROM, floppy disk, hard disk drive(s), solid state memory, DVD, or any other memory storage types or devices, including combinations thereof, which are known to those of ordinary skill in the art. The various storage devices of the memory 20 may be arranged in a tiered storage system to allow for less expensive and larger capacity storage devices, for example, to store less frequently accessed, compressed and/or archived data.


Memory 20 may store one or more non-transitory computer-readable instructions of this technology as illustrated and described with reference to the examples herein that may be executed by the one or more processor(s) 18. The flow charts shown in FIGS. 2 and 3 are representative of example steps or actions of this technology that may be embodied or expressed as one or more non-transitory computer or machine readable instructions stored in memory 20 that may be executed by the processor(s) 18 and/or may be implemented by configured logic in optional configurable logic device 21.


The optional configurable logic device 21 may comprise specialized hardware configured to implement one or more steps of this technology as illustrated and described with reference to the examples herein. By way of example only, the optional configurable logic device 21 may comprise one or more of field programmable gate arrays (FPGAs), field programmable logic devices (FPLDs), application specific integrated circuits (ASICs) and/or programmable logic units (PLUs).


Input and display devices 22 enable a user, such as an administrator, to interact with the network traffic management apparatus 14, such as to input and/or view data and/or to configure, program and/or operate it by way of example only. Input devices may include a keyboard and/or a computer mouse and display devices may include a computer monitor, although other types and numbers of input devices and display devices could be used.


The interface device 24 in the network traffic management apparatus 14 is used to operatively couple and communicate between the network traffic management apparatus 14 and the client computing devices 12 and the servers 16, which are all coupled together by one or more local area networks (LAN) 28 and wide area networks (WAN) 30, although other types and numbers of communication networks or systems with other types and numbers of connections and configurations to other devices and elements. By way of example only, the local area networks (LAN) 28 and wide area networks (WAN) 30 can use TCP/IP over Ethernet and industry-standard protocols, including NFS, CIFS, SOAP, XML, LDAP, and SNMP, although other types and numbers of communication networks, can be used. In this example, the bus 26 is a hyper-transport bus in this example, although other bus types and links may be used, such as PCI.


Each of the client computing devices 12 and the servers 16 include a central processing unit (CPU) or processor, a memory, an interface device, and an I/O system, which are coupled together by a bus or other link, although other numbers and types of network devices could be used. The client computing devices 12, in this example, may run interface applications, such as Web browsers, that may provide an interface to make requests for and send content and/or data to different server-based applications via the LANs 28 and/or WANs 30.


Generally, servers 16 process requests received from client computing devices 12 via LANs 28 and/or WANs 30 according to the HTTP-based application RFC protocol or the CIFS or NFS protocol in this example, but the principles discussed herein are not limited to this example and can include other application protocols. A series of applications may run on the servers 16 that allow the transmission of data, such as object data, files, and/or metadata, requested by the client computing devices 12. The servers 16 may provide data or receive data in response to requests directed toward the respective applications on the servers 16 from the client computing devices 12. In some example, the servers 16 may further include various storage devices including a tiered file storage system and/or may be one or more tiers of a tiered file storage system including one or more other network devices. Accordingly the servers 16 can provide backup, archived, and/or compressed data storage services for other networked devices. It is to be understood that the servers 16 may be hardware or software or may represent a system with multiple servers 16 in a server pool, which may include internal or external networks. In this example the servers 16 may be any version of Microsoft® IIS servers or Apache® servers, although other types of servers may be used. Further, additional servers may be coupled to the LAN 28 and many different types of applications may be available on servers coupled to the LAN 28.


Although an exemplary network environment 10 with client computing devices 12, network traffic management apparatus 14, servers 16, LANs 28 and WANs 30 are described and illustrated herein, other types and numbers of systems, devices, blades, components, and elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).


Furthermore, each of the systems of the examples may be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, and micro-controllers, programmed according to the teachings of the examples, as described and illustrated herein, and as will be appreciated by those of ordinary skill in the art.


In addition, two or more computing systems or devices can be substituted for any one of the systems or devices in any example. Accordingly, principles and advantages of distributed processing, such as redundancy and replication also can be implemented, as desired, to increase the robustness and performance of the devices and systems of the examples. The examples may also be implemented on computer system(s) that extend across any suitable network using any suitable interface mechanisms and traffic technologies, including by way of example only teletraffic in any suitable form (e.g., voice and modem), wireless traffic media, wireless traffic networks, cellular traffic networks, G3 traffic networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, and combinations thereof.


The examples may also be embodied as a non-transitory computer readable medium having instructions stored thereon for one or more aspects of the technology as described and illustrated by way of the examples herein, which when executed by a processor (or configurable hardware), cause the processor to carry out the steps necessary to implement the methods of the examples, as described and illustrated herein.


An exemplary method for servicing read data access requests in a compressed file system will now be described with reference to FIGS. 1-2. In this particular example, in step 200, the network traffic management apparatus 14 obtains at least one original write request including at least the object data to be stored, although in other examples the data may already compressed and stored as described here with reference to steps 200, 202, 204, and 206.


In step 202, the network traffic management apparatus 14 compresses the object data into at least one compressed block. In some examples, each compressed block has a fixed size or length, such as 64 kilobytes, for example, although the compressed blocks may be any other fixed size or of variable size.


In step 204, the network traffic management apparatus 14 stores the compressed blocks in the memory 20, although the compressed blocks can be stored in other data storage devices and at other locations. For example, the compressed blocks could be stored in one or more file server devices 16, a tiered storage system including the memory 20 and/or one or more file server devices 16, and/or any other data storage device(s).


In step 206, the network traffic management apparatus 14 maintains and stores a mapping of the original object data to the compressed blocks of object data, which the network traffic management apparatus 14 in the memory 20, although the mapping could be stored in other locations. One exemplary mapping is a table including object identifier, start offset, and length values for the object data included in the original write request associated with a unique identifier of the compressed block storing the compressed object data for the portion of the object data indicated by the associated start offset and length values, although other mappings of the original object data to the compressed object data can be used.


In one example, the unique identifier for each compressed block includes a file handle or other identifier shared by a plurality of compressed blocks storing compressed data for the same object as well as a start offset and a length value that together uniquely identify each compressed block. In the latter example, and in the exemplary operation in which the compressed blocks are of a fixed size, the length values will all be the same and the start offsets will all be intervals determined by the length value. In order to locate the compressed blocks at a later time, the network traffic management apparatus 14 can store a mapping of the unique identifier for each compressed block to a location of the compressed block in the data storage device or utilize any other method of maintaining the location of the compressed blocks.


In step 208, the network traffic management apparatus 14 obtains a read data access request from a client computing device 12 for object data previously stored as described and illustrated earlier with respect to steps 200, 202, 204, and 206. The read request can be based on any protocol requiring at least object identifier or file handle, start offset, and length parameters, the length parameter indicating a number of bytes, for example, including a common Internet file system (CIFS) protocol, a network file system (NFS) protocol, or a file transfer protocol (FTP), for example.


In step 210, the network traffic management apparatus 14 identifies at least one compressed block storing compressed object data required to service the read request by querying the table based on the read request parameter values. Accordingly, in one example, a read request is obtained by the network traffic management apparatus 14 from a client computing device 12 including at least parameter values F0 for the object identifier, 50 for the start offset, and 100 for the length. In this example, the mapping stored in step 206 for object F0 indicates that the compressed block having a unique identifier of C0 is storing start offset 0 and length 100, the compressed block having a unique identifier of C1 is storing start offset 100 and length 100, and the compressed block having a unique identifier of C2 is storing start offset 200 and length 75. Accordingly, in step 210, the network traffic management apparatus 14 identifies compressed blocks C0 and C1 based on the mapping of the object data byte range 50-150, as identified by the read request parameter values of 50 for the start offset and 100 for the length.


In step 212, the network traffic management apparatus 14 retrieves the identified compressed blocks from the data storage device. Accordingly, in this example, the network traffic management apparatus 14 retrieves compressed blocks C0 and C1 from a data storage device, such as one of server devices 16.


In step 214, the network traffic management apparatus 14 obtains the requested object data by decompressing the retrieved compressed blocks. Accordingly, in this example, blocks C0 and C1 are decompressed by the network traffic management apparatus 14 and the object data responsive to the received read request in step 208 is obtained based on the read request parameter values.


In step 216, the obtained object data is sent by the network traffic management apparatus 14 to the requesting one of the client computing devices 12. Because the read request included parameter values of 50 for the start offset and 100 for the length, in this example, only the second 50 bytes of object data included in compressed block C0 and only the first 50 bytes of object data included in compressed block C1 are obtained by the network traffic management apparatus 14, in step 214, and sent by the network traffic management apparatus 14, in step 216, to the requesting one of the client computing devices 12.


Accordingly, in this example, the read request received from the client computing device 12 is serviced by the network traffic management apparatus 14 without retrieving compressed block C2 from the data storage device and without decompressing compressed block C2. The ability of the network traffic management apparatus 14 to retrieve and decompress only those compressed blocks necessary to service a read request from a client computing device 12 is made possible by the mapping, stored in step 206, which allows the network traffic management apparatus 14 to identify only a subset of compressed blocks. As compressed files and objects are often archived in relatively slow data storage devices due to their relatively infrequent access by users of client computing devices 12, retrieving and decompressing only those necessary compressed blocks, instead of all compressed blocks storing object data for the object identified in the read request, can reduce resource utilization and response time, particularly when the number of compressed blocks not required to service the read request is substantial.


Referring to FIGS. 1 and 3, an exemplary method for servicing write data access requests in a compressed file system will now be described. In this particular example, the write request is a request to modify object data previously stored in the compressed file system as described with reference to steps 300, 302, 304, and 306.


In step 300, the network traffic management apparatus 14 obtains an original write request including at least the object data to be stored.


In step 302, the network traffic management apparatus 14 compresses the object data into at least one compressed block. In this example, each of the compressed blocks includes compressed object data and at least one empty portion. In some examples, the compressed blocks each have a fixed size, such as 64 kilobytes, 4 kilobytes of which is empty and does not include compressed object data, although any size of compressed block, compressed object data, and empty storage space can be used.


In step 304, the network traffic management apparatus 14 stores the compressed blocks in a data storage device such as the memory 20 of the network traffic management apparatus 14, one or more file server devices 16, a tiered storage system including the memory 20 and/or one or more file server devices 16, and/or any other data storage device(s).


In step 306, the network traffic management apparatus 14 maintains and stores a mapping of the original object data to the compressed blocks of object data.


In step 308, the network traffic management apparatus 14 obtains a write request from a client computing device 12 including a plurality of parameter values and object data to be used to modify object data previously stored as described and illustrated earlier with respect to steps 300, 302, 304, and 306. The write request can be based on any protocol requiring at least an object identifier or parameter value identifying the object to be modified, a start offset parameter value indicating the beginning location in the object to be modified, and a length parameter value indicating the portion of the object data to be modified. Accordingly, the protocol can include CIFS, NFS, or FTP, for example.


In step 310, the network traffic management apparatus 14 identifies at least one compressed block storing compressed object data required to service the write request by referencing the mapping, such as by querying a table storing the mapping, based on the write request parameter values. In step 312, the network traffic management apparatus 14 retrieves the identified compressed blocks.


In step 314, the network traffic management apparatus 14 obtains the object data to be modified by decompressing the retrieved compressed blocks. As at least a subset of the parameters are the same for a read request as for a write request, the identification of step 310, retrieval of step 312, and obtaining of step 314 can be performed by the network traffic management apparatus 14 as described and illustrated earlier with respect to steps 210, 212, and 214, respectively.


In step 316, the network traffic management apparatus 14 modifies the object data obtained in step 314 to include at least a portion of the object data included in the write request. In step 318, the network traffic management apparatus 14 generates modified compressed blocks by compressing the modified object data. Accordingly, the modified compressed blocks include compressed write request object data along with compressed object data that was previously stored and not currently modified.


The modified compressed blocks may be smaller, the same size, or larger than the corresponding compressed blocks retrieved, in step 312, by the network traffic management apparatus 14, depending on the size of the write request object data, the size of any previously stored object data that is replaced by the write request object data, and/or the compressibility of the object data as modified, for example. If a modified compressed block is not greater than the corresponding retrieved compressed block, the network traffic management apparatus 14 completes service of the write request by replacing, in step 320, the retrieved compressed block with the modified compressed block.


If the size of any compressed block is greater than the corresponding retrieved compressed block, the network traffic management apparatus 14 can retrieve every compressed block storing object data for the object identified by the write request object identifier parameter value, as identified based on the mapping. The network traffic management apparatus 14 can then decompress all of the retrieved compressed blocks, recompress the object data, and update the mapping. Because such an operation is relatively expensive, particularly with respect to compressed and archived data stored on relatively slow data storage device(s), including the empty portion in each compressed block when compressing the object data, in step 302, can provide for expansion of the compressed data upon servicing the write request, thereby reducing the number of instances in which a modified compressed block is greater in size than a corresponding retrieved compressed block.


Accordingly, in this example, in order to service a write data access request received from a client computing device 12, only those compressed blocks storing compressed object data required to service the write request are retrieved and decompressed by the network traffic management apparatus 14. Additionally, in examples in which a space for expansion is included by the network traffic management apparatus 14 in the form of an empty portion in the compressed blocks, the number of instances in which compressed blocks other than those necessary to service the write request will need to be retrieved, decompressed, recompressed, and stored can be reduced, thereby reducing resource utilization and response time.


The examples described herein have particular advantages for applications in which only portions of an archived object or file are read by a client computing device 12. Additionally, the examples described herein have particular advantages for applications in which only portions of an object or file are written such as databases and document and source control systems, for example, although these examples also provide advantages for other applications.


With this technology a mapping of object data to compressed blocks, each including compressed object data, is maintained and stored by the network traffic management apparatus 14 upon receiving an original write request. Subsequent read and write requests requiring access to the object data can be serviced by the network traffic management apparatus 14 based on the mapping and by only retrieving and decompressing, and in the case of some write requests, modifying and recompressing, only the compressed blocks required to service the requests. By accessing fewer compressed blocks in order to service data access requests, resource utilization is reduced and response time for servicing the data access request is reduced for the user of the requesting one of the client computing devices 12.


Having thus described the basic concept of the invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the invention. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.

Claims
  • 1. A method for accessing data in a compressed file system, comprising: obtaining, by a network traffic management apparatus, at least one original write request from a client computing device comprising object data;compressing, by the network traffic management apparatus, the object data into a plurality of compressed blocks;generating, by the network traffic management apparatus, a mapping of each of the plurality of compressed blocks to a corresponding portion of the object data, wherein every corresponding portion of the object data is represented in the mapping by a corresponding unique object identifier, a start offset, and a length; andservicing, by the network traffic management apparatus, at least one subsequent data access request for at least a portion of the object data, the servicing comprising obtaining at least the requested portion of the object data from the mapped one of the plurality of compressed blocks based on the unique object identifier, the start offset and the length.
  • 2. The method as set forth in claim 1 wherein the servicing further comprises: obtaining, by the network traffic management apparatus, the data access request from the client computing device, wherein the data access request comprises a value for a plurality of parameters comprising the object identifier, the start offset, and the length;identifying, by the network traffic management apparatus, the mapped at least one compressed block based at least in part on the mapping and one or more of the data access request parameter values;retrieving, by the network traffic management apparatus, the identified compressed block;obtaining, by the network traffic management apparatus, at least a portion of the object data identified by the data access request parameter values; anddecompressing, by the network traffic management apparatus, the retrieved compressed block.
  • 3. The method as set forth in claim 2 wherein the data access request is a read request, the method further comprising: sending, by the network traffic management apparatus, the obtained object data to the requesting client computing device.
  • 4. The method as set forth in claim 2 wherein the data access request is a write request, the write request further comprises object data, and wherein the compressing, with the network traffic management apparatus, the object data into a plurality of compressed blocks further comprises: compressing, by the network traffic management apparatus, the object data into a plurality of compressed blocks each including compressed object data and an empty portion, the method further comprising replacing, by the network traffic management apparatus, the retrieved compressed block with a modified compressed block comprising, compressed write request object data when a size of the modified compressed block is not greater than a size of the retrieved compressed block.
  • 5. The method as set forth in claim 4 further comprising: modifying, by the network traffic management apparatus, the object data to include at least a portion of the object data included in the write request;generating, by the network traffic management apparatus, the modified compressed block; andcompressing, by the network traffic management apparatus, the modified object data.
  • 6. The method as set forth in claim 2 wherein the data access request is based on a protocol comprising a common Internet file system (CIFS) protocol, a network file system (NFS) protocol, or a file transfer protocol (FTP).
  • 7. The method as set forth in claim 1 further comprising; storing, by the network traffic management apparatus, the compressed blocks and the mapping in at least one data storage device.
  • 8. The method as set forth in claim 7, wherein the at least one data storage device comprises tiered storage, a memory of a network traffic management apparatus, or a file server device.
  • 9. A non-transitory computer readable medium having stored thereon instructions for accessing data in a compressed file system comprising machine executable code which when executed by at least one processor, causes the processor to perform steps comprising: obtaining at least one original write request from a client computing device comprising object data;compressing the object data into a plurality of compressed blocks;generating a mapping of each of the plurality of compressed blocks to a portion of the object data, wherein every corresponding portion of the object data is represented in the mapping by a corresponding unique object identifier, a start offset, and a length; andservicing at least one subsequent data access request for one of the portions of the object data, wherein the servicing comprises obtaining at least the requested portion of the object data from the mapped one of the plurality of compressed blocks based on the unique object identifier, the start offset and the length.
  • 10. The medium as set forth in claim 9 wherein the servicing further comprises: obtaining the data access request from the client computing device, wherein the data access request comprises a value for a plurality of parameters comprising the object identifier, the start offset, and the length;identifying the mapped at least one compressed block based at least in part on the mapping and one or more of the data access request parameter values;retrieving the identified compressed block;obtaining at least a portion of the object data identified by the data access request parameter values; anddecompressing the retrieved compressed block.
  • 11. The medium as set forth in claim 10 wherein the data access request is a read request, the medium further having stored thereon instructions that when executed by the at least one processor cause the processor to perform steps further comprising: sending the obtained object data to the requesting client computing device.
  • 12. The medium as set forth in claim 10 wherein the data access request is a write request, the write request further comprises object data, and the compressing the object data into a plurality of compressed blocks further comprises: compressing the object data into a plurality of compressed blocks each comprising compressed object data and an empty portion, the medium further comprising replacing the retrieved compressed block with a modified compressed block comprising compressed write request object data when a size of the modified compressed block is not greater than a size of the retrieved compressed block.
  • 13. The medium as set forth in claim 12 further having stored thereon instructions that when executed by the processor cause the processor to perform steps further comprising: modifying the object data to include at least a portion of the object data included in the write request; andgenerating the modified compressed block; andcompressing the modified object data.
  • 14. The medium as set forth in claim 10 wherein the data access request is based on a protocol comprising a common Internet file system (CIFS) protocol, a network file system (NFS) protocol, or a file transfer protocol (FTP).
  • 15. The medium as set forth in claim 9 further having stored thereon instructions that when executed by the processor cause the processor to perform steps further comprising: storing, the compressed blocks and the mapping in at least one data storage device.
  • 16. The medium as set forth in claim 15, wherein the at least one data storage device comprises tiered storage, a memory of a network traffic management apparatus, or a file server device.
  • 17. A network traffic management apparatus comprising: a memory;configurable logic; anda processor coupled to the memory and the configurable logic, at least one of the configurable logic configured to implement or the processor configured to execute programmed instructions stored in the memory comprising: obtaining at least one original write request from a client computing device comprising object data;compressing the object data into a plurality of compressed blocks;generating a mapping of each of the plurality of compressed blocks to a portion of the object data, wherein every corresponding portion of the object data is represented in the mapping by a corresponding unique object identifier, a start offset, and a length; andservicing at least one subsequent data access request for one of the portions of the object data, wherein the servicing comprises at least the requested portion of the object data from the mapped one of the plurality of compressed blocks based on the unique object identifier, the start offset and the length.
  • 18. The apparatus as set forth in claim 17 wherein the servicing further comprises: obtaining, the data access request from the client computing device, wherein the data access request comprises a value for a plurality of parameters comprising the object identifier, the start offset, and the length;identifying, the mapped at least one compressed block based at least in part on the mapping and one or more of the data access request parameter values;retrieving, the identified compressed block;obtaining, at least a portion of the object data identified by the data access request parameter values: anddecompressing the retrieved compressed block.
  • 19. The apparatus as set forth in claim 18 wherein the data access request is a read request and wherein at least one of the configurable logic is configured to implement or the processor is further configured to execute, programmed instructions stored in the memory further comprising: sending the obtained object data to the requesting client computing device.
  • 20. The apparatus as set forth in claim 18 wherein the data access request is a write request, the write request further includes object data, wherein the compressing the object data into a plurality of compressed blocks further comprises: compressing the object data into a plurality of compressed blocks each including compressed object data and an empty portion, and wherein at least one of the configurable logic configured to implement or the processor are further configured to execute programmed instructions stored in the memory further comprising:replacing the retrieved compressed block with a modified compressed block including compressed write request object data when a size of the modified compressed block is not greater than a size of the retrieved compressed block.
  • 21. The apparatus as set forth in claim 20 wherein at least one of the configurable logic is configured to implement or the processor is further configured to execute, programmed instructions stored in the memory further comprising: modifying the object data to include at least a portion of the object data included in the write request; andgenerating the modified compressed block; andcompressing the modified object data.
  • 22. The apparatus as set forth in claim 18 wherein the data access request is based on a protocol comprising a common Internet file system (CIFS) protocol, a network file system (NFS) protocol, or a file transfer protocol (FTP).
  • 23. The apparatus as set forth in claim 17 wherein the processor is further configured to execute programmed instructions stored in the memory further comprising: storing, the compressed blocks and the mapping in at least one data storage device.
  • 24. The apparatus as set forth in claim 23, wherein the at least one data storage device comprises tiered storage, a memory of a network traffic management apparatus, or a file server device.
US Referenced Citations (441)
Number Name Date Kind
4993030 Krakauer et al. Feb 1991 A
5218695 Noveck et al. Jun 1993 A
5303368 Kotaki Apr 1994 A
5473362 Fitzgerald et al. Dec 1995 A
5511177 Kagimasa et al. Apr 1996 A
5537585 Blickenstaff et al. Jul 1996 A
5548724 Akizawa et al. Aug 1996 A
5550965 Gabbe et al. Aug 1996 A
5583995 Gardner et al. Dec 1996 A
5586260 Hu Dec 1996 A
5590320 Maxey Dec 1996 A
5623490 Richter et al. Apr 1997 A
5649194 Miller et al. Jul 1997 A
5649200 Leblang et al. Jul 1997 A
5668943 Attanasio et al. Sep 1997 A
5692180 Lee Nov 1997 A
5721779 Funk Feb 1998 A
5724512 Winterbottom Mar 1998 A
5806061 Chaudhuri et al. Sep 1998 A
5832496 Anand et al. Nov 1998 A
5832522 Blickenstaff et al. Nov 1998 A
5838970 Thomas Nov 1998 A
5862325 Reed et al. Jan 1999 A
5884303 Brown Mar 1999 A
5889935 Ofek et al. Mar 1999 A
5893086 Schmuck et al. Apr 1999 A
5897638 Lasser et al. Apr 1999 A
5901327 Ofek May 1999 A
5905990 Inglett May 1999 A
5917998 Cabrera et al. Jun 1999 A
5920873 Van Huben et al. Jul 1999 A
5926816 Bauer et al. Jul 1999 A
5937406 Balabine et al. Aug 1999 A
5991302 Berl et al. Nov 1999 A
5995491 Richter et al. Nov 1999 A
5999664 Mahoney et al. Dec 1999 A
6012083 Savitzky et al. Jan 2000 A
6029168 Frey Feb 2000 A
6044367 Wolff Mar 2000 A
6044444 Ofek Mar 2000 A
6047129 Frye Apr 2000 A
6072942 Stockwell et al. Jun 2000 A
6078929 Rao Jun 2000 A
6085234 Pitts et al. Jul 2000 A
6088694 Burns et al. Jul 2000 A
6104706 Richter et al. Aug 2000 A
6128627 Mattis et al. Oct 2000 A
6128717 Harrison et al. Oct 2000 A
6161145 Bainbridge et al. Dec 2000 A
6161185 Guthrie et al. Dec 2000 A
6181336 Chiu et al. Jan 2001 B1
6202156 Kalajan Mar 2001 B1
6223206 Dan et al. Apr 2001 B1
6233648 Tomita May 2001 B1
6237008 Beal et al. May 2001 B1
6256031 Meijer et al. Jul 2001 B1
6282610 Bergsten Aug 2001 B1
6289345 Yasue Sep 2001 B1
6308162 Ouimet et al. Oct 2001 B1
6324581 Xu et al. Nov 2001 B1
6329985 Tamer et al. Dec 2001 B1
6339785 Feigenbaum Jan 2002 B1
6349343 Foody et al. Feb 2002 B1
6370543 Hoffert et al. Apr 2002 B2
6374263 Bunger et al. Apr 2002 B1
6374336 Peters et al. Apr 2002 B1
6389433 Bolosky et al. May 2002 B1
6393581 Friedman et al. May 2002 B1
6397246 Wolfe May 2002 B1
6412004 Chen et al. Jun 2002 B1
6438595 Blumenau et al. Aug 2002 B1
6466580 Leung Oct 2002 B1
6469983 Narayana et al. Oct 2002 B2
6477544 Bolosky et al. Nov 2002 B1
6487561 Ofek et al. Nov 2002 B1
6493804 Soltis et al. Dec 2002 B1
6516350 Lumelsky et al. Feb 2003 B1
6516351 Borr Feb 2003 B2
6542909 Tamer et al. Apr 2003 B1
6549916 Sedlar Apr 2003 B1
6553352 Delurgio et al. Apr 2003 B2
6556997 Levy Apr 2003 B1
6556998 Mukherjee et al. Apr 2003 B1
6560230 Li et al. May 2003 B1
6601101 Lee et al. Jul 2003 B1
6606663 Liao et al. Aug 2003 B1
6612490 Herrendoerfer et al. Sep 2003 B1
6654346 Mahalingaiah et al. Nov 2003 B1
6697871 Hansen Feb 2004 B1
6704755 Midgley et al. Mar 2004 B2
6721794 Taylor et al. Apr 2004 B2
6728265 Yavatkar et al. Apr 2004 B1
6738357 Richter et al. May 2004 B1
6738790 Klein et al. May 2004 B1
6742035 Zayas et al. May 2004 B1
6744776 Kalkunte et al. Jun 2004 B1
6748420 Quatrano et al. Jun 2004 B1
6754215 Arikawa et al. Jun 2004 B1
6757706 Dong et al. Jun 2004 B1
6775672 Mahalingam et al. Aug 2004 B2
6775673 Mahalingam et al. Aug 2004 B2
6775679 Gupta Aug 2004 B2
6782450 Arnott et al. Aug 2004 B2
6801960 Ericson et al. Oct 2004 B1
6826613 Wang et al. Nov 2004 B1
6839761 Kadyk et al. Jan 2005 B2
6847959 Arrouye et al. Jan 2005 B1
6847970 Keller et al. Jan 2005 B2
6850997 Rooney et al. Feb 2005 B1
6868439 Basu et al. Mar 2005 B2
6871245 Bradley Mar 2005 B2
6880017 Marce et al. Apr 2005 B1
6889249 Miloushev et al. May 2005 B2
6914881 Mansfield et al. Jul 2005 B1
6922688 Frey, Jr. Jul 2005 B1
6934706 Mancuso et al. Aug 2005 B1
6938039 Bober et al. Aug 2005 B1
6938059 Tamer et al. Aug 2005 B2
6959373 Testardi Oct 2005 B2
6961815 Kistler et al. Nov 2005 B2
6973455 Vahalia et al. Dec 2005 B1
6973549 Testardi Dec 2005 B1
6975592 Seddigh et al. Dec 2005 B1
6985936 Agarwalla et al. Jan 2006 B2
6985956 Luke et al. Jan 2006 B2
6986015 Testardi Jan 2006 B2
6990114 Erimli et al. Jan 2006 B1
6990547 Ulrich et al. Jan 2006 B2
6990667 Ulrich et al. Jan 2006 B2
6996841 Kadyk et al. Feb 2006 B2
6999912 Loisey et al. Feb 2006 B2
7003533 Noguchi et al. Feb 2006 B2
7006981 Rose et al. Feb 2006 B2
7010553 Chen et al. Mar 2006 B2
7013379 Testardi Mar 2006 B1
7020644 Jameson Mar 2006 B2
7020669 McCann et al. Mar 2006 B2
7024427 Bobbitt et al. Apr 2006 B2
7039061 Connor et al. May 2006 B2
7051112 Dawson May 2006 B2
7054998 Arnott et al. May 2006 B2
7055010 Lin et al. May 2006 B2
7072917 Wong et al. Jul 2006 B2
7075924 Richter et al. Jul 2006 B2
7089286 Malik Aug 2006 B1
7111115 Peters et al. Sep 2006 B2
7113962 Kee et al. Sep 2006 B1
7120728 Krakirian et al. Oct 2006 B2
7120746 Campbell et al. Oct 2006 B2
7127556 Blumenau et al. Oct 2006 B2
7133967 Fujie et al. Nov 2006 B2
7143146 Nakatani et al. Nov 2006 B2
7146524 Patel et al. Dec 2006 B2
7152184 Maeda et al. Dec 2006 B2
7155466 Rodriguez et al. Dec 2006 B2
7165095 Sim Jan 2007 B2
7167821 Hardwick et al. Jan 2007 B2
7171469 Ackaouy et al. Jan 2007 B2
7173929 Testardi Feb 2007 B1
7181523 Sim Feb 2007 B2
7194579 Robinson et al. Mar 2007 B2
7197615 Arakawa et al. Mar 2007 B2
7219260 de Forest et al. May 2007 B1
7234074 Cohn et al. Jun 2007 B2
7236491 Tsao et al. Jun 2007 B2
7237076 Nakano et al. Jun 2007 B2
7243089 Becker-Szendy et al. Jul 2007 B2
7243094 Tabellion et al. Jul 2007 B2
7263610 Parker et al. Aug 2007 B2
7269168 Roy et al. Sep 2007 B2
7269582 Winter et al. Sep 2007 B2
7272613 Sim et al. Sep 2007 B2
7280536 Testardi Oct 2007 B2
7284150 Ma et al. Oct 2007 B2
7293097 Borr Nov 2007 B2
7293099 Kalajan Nov 2007 B1
7293133 Colgrove et al. Nov 2007 B1
7299250 Douceur et al. Nov 2007 B2
7308475 Pruitt et al. Dec 2007 B1
7330486 Ko et al. Feb 2008 B2
7343398 Lownsbrough Mar 2008 B1
7346664 Wong et al. Mar 2008 B2
7373345 Carpentier et al. May 2008 B2
7373520 Borthakur et al. May 2008 B1
7383288 Miloushev et al. Jun 2008 B2
7383463 Hayden et al. Jun 2008 B2
7401220 Bolosky et al. Jul 2008 B2
7406484 Srinivasan et al. Jul 2008 B1
7415488 Muth et al. Aug 2008 B1
7415608 Bolosky et al. Aug 2008 B2
7418439 Wong Aug 2008 B2
7437358 Arrouye et al. Oct 2008 B2
7440982 Lu et al. Oct 2008 B2
7457982 Rajan Nov 2008 B2
7467158 Marinescu Dec 2008 B2
7475241 Patel et al. Jan 2009 B2
7477796 Sasaki et al. Jan 2009 B2
7509322 Miloushev et al. Mar 2009 B2
7512673 Miloushev et al. Mar 2009 B2
7519813 Cox et al. Apr 2009 B1
7562110 Miloushev et al. Jul 2009 B2
7571168 Bahar et al. Aug 2009 B2
7574433 Engel Aug 2009 B2
7587471 Yasuda et al. Sep 2009 B2
7590747 Coates et al. Sep 2009 B2
7599941 Bahar et al. Oct 2009 B2
7610307 Havewala et al. Oct 2009 B2
7610390 Yared et al. Oct 2009 B2
7624109 Testardi Nov 2009 B2
7639883 Gill Dec 2009 B2
7644109 Manley et al. Jan 2010 B2
7653699 Colgrove et al. Jan 2010 B1
7656788 Ma et al. Feb 2010 B2
7680836 Anderson et al. Mar 2010 B2
7685126 Patel et al. Mar 2010 B2
7685177 Hagerstrom et al. Mar 2010 B1
7689596 Tsunoda Mar 2010 B2
7694082 Golding et al. Apr 2010 B2
7711771 Kirnos May 2010 B2
7725763 Vertes et al. May 2010 B2
7734603 McManis Jun 2010 B1
7739540 Akutsu et al. Jun 2010 B2
7743031 Cameron et al. Jun 2010 B1
7743035 Chen et al. Jun 2010 B2
7752294 Meyer et al. Jul 2010 B2
7769711 Srinivasan et al. Aug 2010 B2
7788335 Miloushev et al. Aug 2010 B2
7805470 Armangau et al. Sep 2010 B2
7809691 Karmarkar et al. Oct 2010 B1
7818299 Federwisch et al. Oct 2010 B1
7822939 Veprinsky et al. Oct 2010 B1
7831639 Panchbudhe et al. Nov 2010 B1
7849112 Mane et al. Dec 2010 B2
7853958 Mathew et al. Dec 2010 B2
7870154 Shitomi et al. Jan 2011 B2
7877511 Berger et al. Jan 2011 B1
7885970 Lacapra Feb 2011 B2
7886218 Watson Feb 2011 B2
7900002 Lyon Mar 2011 B2
7903554 Manur et al. Mar 2011 B1
7904466 Valencia et al. Mar 2011 B1
7913053 Newland Mar 2011 B1
7937421 Mikesell et al. May 2011 B2
7953085 Chang et al. May 2011 B2
7953701 Okitsu et al. May 2011 B2
7958347 Ferguson Jun 2011 B1
7984108 Landis et al. Jul 2011 B2
8005953 Miloushev et al. Aug 2011 B2
8015157 Kamei et al. Sep 2011 B2
8046547 Chatterjee et al. Oct 2011 B1
8055724 Amegadzie et al. Nov 2011 B2
8074107 Sivasubramanian et al. Dec 2011 B2
8099758 Schaefer et al. Jan 2012 B2
8103622 Karinta Jan 2012 B1
8112392 Bunnell et al. Feb 2012 B1
8117244 Marinov et al. Feb 2012 B2
8171124 Kondamuru May 2012 B2
8209403 Szabo et al. Jun 2012 B2
8271751 Hinrichs, Jr. Sep 2012 B2
8306948 Chou et al. Nov 2012 B2
8326798 Driscoll et al. Dec 2012 B1
8351600 Resch Jan 2013 B2
8417746 Gillett, Jr. et al. Apr 2013 B1
8468542 Jacobson et al. Jun 2013 B2
8498951 Baluja et al. Jul 2013 B1
8572007 Manadhata et al. Oct 2013 B1
8576283 Foster et al. Nov 2013 B1
8595547 Sivasubramanian et al. Nov 2013 B1
8620879 Cairns Dec 2013 B2
8676753 Sivasubramanian et al. Mar 2014 B2
8745266 Agarwal et al. Jun 2014 B2
20010007560 Masuda et al. Jul 2001 A1
20010047293 Waller et al. Nov 2001 A1
20020012382 Schilling Jan 2002 A1
20020035537 Waller et al. Mar 2002 A1
20020059263 Shima et al. May 2002 A1
20020087887 Busam et al. Jul 2002 A1
20020106263 Winker Aug 2002 A1
20020120763 Miloushev et al. Aug 2002 A1
20020143909 Botz et al. Oct 2002 A1
20020150253 Brezak et al. Oct 2002 A1
20020156905 Weissman Oct 2002 A1
20020161911 Pinckney, III et al. Oct 2002 A1
20020178410 Haitsma et al. Nov 2002 A1
20020194342 Lu et al. Dec 2002 A1
20030012382 Ferchichi et al. Jan 2003 A1
20030028514 Lord et al. Feb 2003 A1
20030033308 Patel et al. Feb 2003 A1
20030033535 Fisher et al. Feb 2003 A1
20030065956 Belapurkar et al. Apr 2003 A1
20030128708 Inoue et al. Jul 2003 A1
20030140210 Testardi Jul 2003 A1
20030156586 Lee et al. Aug 2003 A1
20030159072 Bellinger et al. Aug 2003 A1
20030171978 Jenkins et al. Sep 2003 A1
20030177364 Walsh et al. Sep 2003 A1
20030177388 Botz et al. Sep 2003 A1
20030179755 Fraser Sep 2003 A1
20030200207 Dickinson Oct 2003 A1
20030204635 Ko et al. Oct 2003 A1
20040003266 Moshir et al. Jan 2004 A1
20040006575 Visharam et al. Jan 2004 A1
20040010654 Yasuda et al. Jan 2004 A1
20040017825 Stanwood et al. Jan 2004 A1
20040028043 Maveli et al. Feb 2004 A1
20040030857 Krakirian et al. Feb 2004 A1
20040044705 Stager et al. Mar 2004 A1
20040054748 Ackaouy et al. Mar 2004 A1
20040093474 Lin et al. May 2004 A1
20040098595 Aupperle et al. May 2004 A1
20040133577 Miloushev et al. Jul 2004 A1
20040133606 Miloushev et al. Jul 2004 A1
20040139355 Axel et al. Jul 2004 A1
20040153479 Mikesell et al. Aug 2004 A1
20040199547 Winter et al. Oct 2004 A1
20040213156 Smallwood et al. Oct 2004 A1
20040236798 Srinivasan et al. Nov 2004 A1
20040250032 Ji et al. Dec 2004 A1
20050027862 Nguyen et al. Feb 2005 A1
20050050107 Mane et al. Mar 2005 A1
20050071589 Tross et al. Mar 2005 A1
20050091214 Probert et al. Apr 2005 A1
20050108575 Yung May 2005 A1
20050114701 Atkins et al. May 2005 A1
20050117589 Douady et al. Jun 2005 A1
20050160161 Barrett et al. Jul 2005 A1
20050160243 Lubbers et al. Jul 2005 A1
20050175013 Le Pennec et al. Aug 2005 A1
20050187866 Lee Aug 2005 A1
20050193245 Hayden et al. Sep 2005 A1
20050198501 Andreev et al. Sep 2005 A1
20050213587 Cho et al. Sep 2005 A1
20050246393 Coates et al. Nov 2005 A1
20050289111 Tribble et al. Dec 2005 A1
20060010502 Mimatsu et al. Jan 2006 A1
20060045096 Farmer et al. Mar 2006 A1
20060074922 Nishimura Apr 2006 A1
20060075475 Boulos et al. Apr 2006 A1
20060080353 Miloushev et al. Apr 2006 A1
20060106882 Douceur et al. May 2006 A1
20060112399 Lessly May 2006 A1
20060123062 Bobbitt et al. Jun 2006 A1
20060140193 Kakani et al. Jun 2006 A1
20060153201 Hepper et al. Jul 2006 A1
20060167838 Lacapra Jul 2006 A1
20060179261 Rajan Aug 2006 A1
20060184589 Lees et al. Aug 2006 A1
20060200470 Lacapra et al. Sep 2006 A1
20060206547 Kulkarni et al. Sep 2006 A1
20060218135 Bisson et al. Sep 2006 A1
20060224636 Kathuria et al. Oct 2006 A1
20060224687 Popkin et al. Oct 2006 A1
20060230265 Krishna Oct 2006 A1
20060242179 Chen et al. Oct 2006 A1
20060259949 Schaefer et al. Nov 2006 A1
20060268692 Wright et al. Nov 2006 A1
20060270341 Kim et al. Nov 2006 A1
20060271598 Wong et al. Nov 2006 A1
20060277225 Mark et al. Dec 2006 A1
20060282461 Marinescu Dec 2006 A1
20060282471 Mark et al. Dec 2006 A1
20060294164 Armangau et al. Dec 2006 A1
20070016754 Testardi Jan 2007 A1
20070024919 Wong et al. Feb 2007 A1
20070027929 Whelan Feb 2007 A1
20070027935 Haselton et al. Feb 2007 A1
20070028068 Golding et al. Feb 2007 A1
20070061441 Landis et al. Mar 2007 A1
20070088702 Fridella et al. Apr 2007 A1
20070136308 Tsirigotis et al. Jun 2007 A1
20070139227 Speirs et al. Jun 2007 A1
20070180314 Kawashima et al. Aug 2007 A1
20070208748 Li Sep 2007 A1
20070209075 Coffman Sep 2007 A1
20070239944 Rupanagunta et al. Oct 2007 A1
20070260830 Faibish et al. Nov 2007 A1
20080046432 Anderson et al. Feb 2008 A1
20080070575 Claussen et al. Mar 2008 A1
20080104347 Iwamura et al. May 2008 A1
20080114718 Anderson et al. May 2008 A1
20080189468 Schmidt et al. Aug 2008 A1
20080200207 Donahue et al. Aug 2008 A1
20080208933 Lyon Aug 2008 A1
20080209073 Tang Aug 2008 A1
20080215836 Sutoh et al. Sep 2008 A1
20080222223 Srinivasan et al. Sep 2008 A1
20080243769 Arbour et al. Oct 2008 A1
20080263401 Stenzel Oct 2008 A1
20080282047 Arakawa et al. Nov 2008 A1
20080294446 Guo et al. Nov 2008 A1
20090007162 Sheehan Jan 2009 A1
20090013138 Sudhakar Jan 2009 A1
20090019535 Mishra et al. Jan 2009 A1
20090037500 Kirshenbaum Feb 2009 A1
20090037975 Ishikawa et al. Feb 2009 A1
20090041230 Williams Feb 2009 A1
20090055507 Oeda Feb 2009 A1
20090055607 Schack et al. Feb 2009 A1
20090077097 Lacapra et al. Mar 2009 A1
20090089344 Brown et al. Apr 2009 A1
20090094252 Wong et al. Apr 2009 A1
20090106255 Lacapra et al. Apr 2009 A1
20090106263 Khalid et al. Apr 2009 A1
20090132616 Winter et al. May 2009 A1
20090161542 Ho Jun 2009 A1
20090187915 Chew et al. Jul 2009 A1
20090204649 Wong et al. Aug 2009 A1
20090204650 Wong et al. Aug 2009 A1
20090204705 Marinov et al. Aug 2009 A1
20090210431 Marinkovic et al. Aug 2009 A1
20090210875 Bolles et al. Aug 2009 A1
20090240705 Miloushev et al. Sep 2009 A1
20090240899 Akagawa et al. Sep 2009 A1
20090265396 Ram et al. Oct 2009 A1
20090313503 Atluri et al. Dec 2009 A1
20100017643 Baba et al. Jan 2010 A1
20100030777 Panwar et al. Feb 2010 A1
20100061232 Zhou et al. Mar 2010 A1
20100082542 Feng et al. Apr 2010 A1
20100122248 Robinson et al. May 2010 A1
20100199042 Bates et al. Aug 2010 A1
20100205206 Rabines et al. Aug 2010 A1
20100211547 Kamei et al. Aug 2010 A1
20100325257 Goel et al. Dec 2010 A1
20100325634 Ichikawa et al. Dec 2010 A1
20110083185 Sheleheda et al. Apr 2011 A1
20110087696 Lacapra Apr 2011 A1
20110093471 Brockway et al. Apr 2011 A1
20110099146 McAlister et al. Apr 2011 A1
20110099420 McAlister et al. Apr 2011 A1
20110107112 Resch May 2011 A1
20110119234 Schack et al. May 2011 A1
20110296411 Tang et al. Dec 2011 A1
20110320882 Beaty et al. Dec 2011 A1
20120042115 Young Feb 2012 A1
20120078856 Linde Mar 2012 A1
20120144229 Nadolski Jun 2012 A1
20120150699 Trapp et al. Jun 2012 A1
20130007239 Agarwal et al. Jan 2013 A1
20130058252 Casado et al. Mar 2013 A1
20130058255 Casado et al. Mar 2013 A1
Foreign Referenced Citations (21)
Number Date Country
2003300350 Jul 2004 AU
2080530 Apr 1994 CA
2512312 Jul 2004 CA
0605088 Feb 1996 EP
0 738 970 Oct 1996 EP
63010250 Jan 1988 JP
6205006 Jul 1994 JP
06-332782 Dec 1994 JP
8021924 Mar 1996 JP
08-328760 Dec 1996 JP
08-339355 Dec 1996 JP
9016510 Jan 1997 JP
11282741 Oct 1999 JP
2000-183935 Jun 2000 JP
566291 Dec 2008 NZ
0239696 May 2002 WO
WO 02056181 Jul 2002 WO
WO 2004061605 Jul 2004 WO
2006091040 Aug 2006 WO
WO 2008130983 Oct 2008 WO
WO 2008147973 Dec 2008 WO
Non-Patent Literature Citations (83)
Entry
“The AFS File System in Distributed Computing Environment,” www.transarc.ibm.com/Library/whitepapers/AFS/afsoverview.html, last accessed on Dec. 20, 2002.
Aguilera et al., “Improving recoverability in multi-tier storage systems,” International Conference on Dependable Systems and Networks (DSN-2007), Jun. 2007, 10 pages, Edinburgh, Scotland.
Anderson et al., “Interposed Request Routing for Scalable Network Storage,” ACM Transactions on Computer Systems 20(1): (Feb. 2002), pp. 1-24.
Anderson et al., “Serverless Network File System,” in the 15th Symposium on Operating Systems Principles, Dec. 1995, 40 pages, Association for Computing Machinery, Inc.
Anonymous, “How DFS Works: Remote File Systems,” Distributed File System (DFS) Mar. 2003, 54 pages, Technical Reference retrieved from the Internet on Feb. 13, 2009, URL<http://technetmicrosoft.com/en-us/library/cc782417(WS.10,printer).aspx>.
Apple, Inc., “Mac OS X Tiger Keynote Intro. Part 2,” Jun. 2004, www.youtube.com <http://www.youtube.com/watch?v=zSBJwEmRJbY>, 1 page.
Apple, Inc., “Tiger Developer Overview Series: Working with Spotlight,” Nov. 23, 2004, www.apple.com using www.archive.org <http://web.archive.org/web/20041123005335/developer.apple.com/macosx/tiger/spo tlight.html>, pp. 1-6.
“A Storage Architecture Guide,” Second Edition, 2001, Auspex Systems, Inc., www.auspex.com, last accessed on Dec. 30, 2002.
Basney et al., “Credential Wallets: A Classification of Credential Repositories Highlighting MyProxy,” Sep. 19-21, 2003, pp. 1-20, 31st Research Conference on Communication, Information and Internet Policy (TPRC 2003), Arlington, Virginia.
Botzum, Keys, “Single Sign on—A Contrarian View,” Aug. 6, 2001, pp. 1-8, Open Group Website, http://www.opengroup.org/security/topics.htm.
Cabrera et al., “Swift: A Storage Architecture for Large Objects,” In Proceedings of the-Eleventh IEEE Symposium on Mass Storage Systems, Oct. 1991, pp. 123-128.
Cabrera et al., “Swift: Using Distributed Disk Striping to Provide High I/O Data Rates,” Fall 1991, pp. 405-436, vol. 4, No. 4, Computing Systems.
Cabrera et al., “Using Data Striping in a Local Area Network,” 1992, 22 pages, Technical report number UCSC-CRL-92-09 of the Computer & Information Sciences Department of University of California at Santa Cruz.
Callaghan et al., “NFS Version 3 Protocol Specifications” (RFC 1813), Jun. 1995, 127 pages, The Internet Engineering Task Force (IETN), www.ietf.org, last accessed on Dec. 30, 2002.
Carns et al., “PVFS: A Parallel File System for Linux Clusters,” in Proceedings of the Extreme Linux Track: 4th Annual Linux Showcase and Conference, Oct. 2000, pp. 317-327, Atlanta, Georgia, USENIX Association.
Cavale, M. R., “Introducing Microsoft Cluster Service (MSCS) in the Windows Server 2003”, Nov. 2002, 10 pages, Microsoft Corporation.
“CSA Persistent File System Technology,” A White Paper, Jan. 1, 1999, pp. 1-3, http://www.cosoa.com/white—papers/pfs.php, Colorado Software Architecture, Inc.
“Distributed File System: A Logical View of Physical Storage: White Paper,” 1999, Microsoft Corp., www.microsoft.com, <http://www.eu.microsoft.com/TechNet/prodtechnol/windows2000serv/maintain/DFSnt95>, pp. 1-26, last accessed on Dec. 20, 2002.
English Translation of Notification of Reason(s) for Refusal for JP 2002-556371 (Dispatch Date: Jan. 22, 2007).
Fan et al., “Summary Cache: A Scalable Wide-Area Protocol”, Computer Communications Review, Association Machinery, New York, USA, Oct. 1998, pp. 254-265, vol. 28, Web Cache Sharing for Computing No. 4.
Farley, M., “Enterprise Storage Forum,” Jan. 2000, 2 pages, Book Review-Building Storage Networks, 2nd Edition, http://www.enterprisestorageforum.com/sans/features/print/0,,10556—1441201.00. html, Enterprise Storage Forum Staff, last accessed Dec. 20, 2002.
Gibson et al., “File Server Scaling with Network-Attached Secure Disks,” in Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (Sigmetrics '97), Association for Computing Machinery, Inc., Jun. 15-18, 1997, 13 pages.
Gibson et al., “NASD Scalable Storage Systems,” Jun. 1999, 6 pages, USENIX99, Extreme Linux Workshop, Monterey, California.
Harrison, C., May 19, 2008 response to Communication pursuant to Article 96(2) EPC dated Nov. 9, 2007 in corresponding European patent application No. 02718824.2.
Hartman, J., “The Zebra Striped Network File System,” 1994, Ph.D. dissertation submitted in the Graduate Division of the University of California at Berkeley.
Haskin et al., “The Tiger Shark File System,” 1996, in proceedings of IEEE, Spring COMPCON, Santa Clara, CA, www.research.ibm.com, last accessed on Dec. 30, 2002.
Hu, J., Final Office action dated Sep. 21, 2007 for related U.S. Appl. No. 10/336,784.
Hu, J., Office action dated Feb. 6, 2007 for related U.S. Appl. No. 10/336,784.
Hwang et al., “Designing SSI Clusters with Hierarchical Checkpointing and Single 1/0 Space,” IEEE Concurrency, Jan.-Mar. 1999, pp. 60-69.
International Search Report for International Patent Application No. PCT/US2008/083117 (Jun. 23, 2009).
International Search Report for International Patent Application No. PCT/US2008/060449 (Apr. 9, 2008).
International Search Report for International Patent Application No. PCT/US2008/064677 (Sep. 6, 2009).
International Search Report for International Patent Application No. PCT /US02/00720, Jul. 8, 2004.
International Search Report from International Application No. PCT/US03/41202, mailed Sep. 15, 2005.
Karamanolis, C. et al., “An Architecture for Scalable and Manageable File Services,” HPL-2001-173, Jul. 26, 2001. pp. 1-114.
Katsurashima, W. et al., “NAS Switch: A Novel CIFS Server Virtualization, Proceedings,” 20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003 (MSST 2003), Apr. 2003.
Kimball, C.E. et al., “Automated Client-Side Integration of Distributed Application Servers,” 13th LISA Conf., 1999, pp. 275-282 of the Proceedings.
Klayman, J., Nov. 13, 2008 e-mail to Japanese associate including instructions for response to office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371.
Klayman, J., Response filed by Japanese associate to office action dated Jan. 22, 2007 in corresponding Japanese patent application No. 2002-556371.
Klayman, J., Jul. 18, 2007 e-mail to Japanese associate including instructions for response to office action dated Jan. 22, 2007 in corresponding Japanese patent application No. 2002-556371.
Kohl et al., “The Kerberos Network Authentication Service (V5),” RFC 1510, Sep. 1993, 105 pages, http://www.ietf.org/ rfc/rfc1510.txt?number=1510.
Korkuzas, V., Communication pursuant to Article 96(2) EPC dated Sep. 11, 2007 in corresponding European patent application No. 02718824.2-2201, 3 pages.
Lelil, S., “Storage Technology News: AutoVirt adds tool to help data migration projects,” Feb. 25, 2011, last accessed Mar. 17, 2011, 3 pages, <http://searchstorage.techtarget.com/news/article/0,289142,sid5—gci1527986,00.html>.
Long et al., “Swift/RAID: A distributed RAID System”, Computing Systems, Summer 1994, 20 pages, vol. 7.
“NERSC Tutorials: I/O on the Cray T3E, ‘Chapter 8, Disk Striping’,” National Energy Research Scientific Computing Center (NERSC), http://hpcfnersc.gov, last accessed on Dec. 27, 2002, 9 pages.
Noghani et al., “A Novel Approach to Reduce Latency on the Internet: ‘Component-Based Download’,” Proceedings of the Computing, Las Vegas, NV, Jun. 2000, pp. 1-6 on the Internet: Intl Conf. on Internet.
Norton et al., “CIFS Protocol Version CIFS-Spec 0.9,” 2001, 125 pages, Storage Networking Industry Association (SNIA), www.snia.org, last accessed on Mar. 26, 2001.
Novotny et al., “An Online Credential Repository for the Grid: MyProxy,” 2001, pp. 1-8.
Pashalidis et al., “A Taxonomy of Single Sign-On Systems,” 2003, pp. 1-16, Royal Holloway, University of London, Egham Surray, TW20, 0EX, United Kingdom.
Pashalidis et al., “Impostor: A Single Sign-On System for Use from Untrusted Devices,” Global Telecommunications Conference, 2004, GLOBECOM '04, IEEE, Issue Date: Nov. 29,-Dec. 3, 2004, 5 pages, Royal Holloway, University of London.
Patterson et al., “A case for redundant arrays of inexpensive disks (RAID)”, Chicago, Illinois, Jun. 1-3, 1998, pp. 109-116, in Proceedings of ACM SIGMOD conference on the Management of Data, Association for Computing Machinery, Inc., www.acm.org, last accessed on Dec. 20, 2002.
Pearson, P.K., “Fast Hashing of Variable-Length Text Strings,” Comm. of the ACM, Jun. 1990, pp. 677-680, vol. 33, No. 6.
Peterson, M., “Introducing Storage Area Networks,” Feb. 1998, 6 pages, InfoStor, www.infostor.com, last accessed on Dec. 20, 2002.
Preslan et al., “Scalability and Failure Recovery in a Linux Cluster File System,” in Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta, Georgia, Oct. 10-14, 2000, pp. 169-180 of the Proceedings, www.usenix.org/publications/library/proceedings/als2000/full—papers/preslan/presl, last accessed on Dec. 20, 2002.
Response filed Jul. 6, 2007 to Office action dated Feb. 6, 2007 for related U.S. Appl. No. 10/336,784, 24 pages.
Response filed Mar. 20, 2008 to Final Office action dated Sep. 21, 2007 for related U.S. Appl. No. 10/336,784, 22 pages.
Rodriguez et al., “Parallel-access for mirror sites in the Internet,” InfoCom 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE Tel Aviv, Israel Mar. 26-30, 2000, Piscataway, NJ, USA, IEEE, US, Mar. 26, 2000, pp. 864-873, XP010376176 ISBN: 0-7803-5880-5 p. 867, col. 2, last paragraph—p. 868, col. 1, paragraph 1.
Rsync, “Welcome to the Rsync Web Pages,” Retrieved from the Internet URL: http://samba.anu.edu.ut.rsync/. (Retrieved on Dec. 18, 2009 ), 5 pages.
Savage, et al., “AFRAID—A Frequently Redundant Array of Independent Disks,” Jan. 22-26, 1996, pp. 1-13, USENIX Technical Conference, San Diego, California.
“Scaling Next Generation Web Infrastructure with Content-Intelligent Switching: White Paper,” Apr. 2000, pp. 1-9, Alteon Web Systems, Inc.
Soltis et al., “The Design and Performance of a Shared Disk File System for IRIX,” Mar. 23-26, 1998, pp. 1-17, Sixth NASA Goddard Space Flight Center Conference on Mass Storage and Technologies in cooperation with the Fifteenth IEEE Symposium on Mass Storage Systems, University of Minnesota.
Soltis et al., “The Global File System,” Sep. 17-19, 1996, 24 pages, in Proceedings of the Fifth NASA Goddard Space Flight Center Conference on Mass Storage Systems and Technologies, College Park, Maryland.
Sorenson, K.M., “Installation and Administration: Kimberlite Cluster Version 1.1.0, Rev. Dec. 2000,” 137 pages, Mission Critical Linux, http://oss.missioncriticallinux.com/kimberlite/kimberlite.pdf.
Stakutis, C., “Benefits of SAN-based file system sharing,” Jul. 2000, pp. 1-4, InfoStor, www.infostor.com, last accessed on Dec. 30, 2002, Penn Well Corporation.
Thekkath et al., “Frangipani: A Scalable Distributed File System,” in Proceedings of the 16th ACM Symposium on Operating Systems Principles, Oct. 1997, pp. 1-14, Association for Computing Machinery, Inc.
Tulloch, Mitch, “Microsoft Encyclopedia of Security,” 2003, pp. 218, 300-301, Microsoft Press, Redmond, Washington.
Uesugi, H., Nov. 26, 2008 amendment filed by Japanese associate in response to office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371, 5 pages.
Uesugi, H., English translation of office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371, 2 pages.
Uesugi, H., Jul. 15, 2008 letter from Japanese associate reporting office action dated May 26, 2008 in corresponding Japanese patent application No. 2002-556371, 2 pages.
“Veritas SANPoint Foundation Suite(tm) and SANPoint Foundation Suite(tm) HA:New Veritas volume Management and File System Technology for Cluster Environments,” Sep. 2001, 26 pages, Veritas Software Corp.
Wilkes, J., et al., “The HP AutoRAID Hierarchical Storage System,” Feb. 1996, 29 pages, vol. 14, No. 1, ACM Transactions on Computer Systems.
“Windows Clustering Technologies—An Overview,” Nov. 2001, 31 pages, Microsoft Corp., www.microsoft.com, last accessed on Dec. 30, 2002.
Zayas, E., “AFS-3 Programmer's Reference: Architectural Overview,” Sep. 2, 1991, 37 pages, Version 1.0 (doc. number FS-00-D160) Transarc Corporation.
Gupta et al., “Algorithms for Packet Classification”, Computer Systems Laboratory, Stanford University, CA, Mar./Apr. 2001, pp. 1-29.
Heinz II G., “Priorities in Stream Transmission Control Protocol (SCTP) Multistreaming”, Thesis submitted to the Faculty of the University of Delaware, Spring 2003, pp. 1-35.
Internet Protocol,“DARPA Internet Program Protocol Specification”, (RFC:791), Information Sciences Institute, University of Southern California, Sep. 1981, pp. 1-49.
Ilvesmaki M., et al., “On the capabilities of application level traffic measurements to differentiate and classify Internet traffic”, Presented in SPIE's International Symposium ITcom, Aug. 19-21, 2001, pp. 1-11, Denver, Colorado.
Modiano E., “Scheduling Algorithms for Message Transmission Over a Satellite Broadcast System,” MIT Lincoln Laboratory Advanced Network Group, Nov. 1997, pp. 1-7.
Ott D., et al., “A Mechanism for TCP-Friendly Transport-level Protocol Coordination”, USENIX Annual Technical Conference, 2002, University of North Carolina at Chapel Hill, pp. 1-12.
Padmanabhan V., et al., “Using Predictive Prefetching to Improve World Wide Web Latency”, SIGCOM, 1996, pp. 1-15.
Rosen E., et al., “MPLS Label Stack Encoding”, (RFC:3032) Network Working Group, Jan. 2001, pp. 1-22, (http://www.ietf.org/rfc/rfc3032.txt).
Wang B., “Priority and Realtime Data Transfer Over the Best-Effort Internet”, Dissertation Abstract, Sep. 2005, ScholarWorks@UMASS.
Woo T.Y.C., “A Modular Approach to Packet Classification: Algorithms and Results”, Nineteenth Annual Conference of the IEEE Computer and Communications Societies 3(3):1213-22, Mar. 26-30, 2000, abstract only, (http://ieeexplore.ieee.org/xpl/freeabs—all.jsp?arnumber=832499).