Fast accessible compressed thin provisioning volume

A computerized data storage system includes at least one storage device including a nonvolatile writable medium; a cache memory operatively coupled to the storage port and including a data storing area and a data management controller and a storage port. The storage port is operable to connect to a host computer, receive and send I/O information required by the host computer. The storage port is also operable to receive a request to read data, and, in response to the request to read data, the storage port is operable to send the data stored in the data storing area of the cache memory. The storage port is further operable to receive a request to write data, and, in response to the request to write data, the storage port is operable to send the write data to the data storing area of the cache memory. The storage system further includes a thin provisioning controller operable to provide a virtual volume having a virtual volume page, a capacity pool having a capacity pool page and manage a mapping between the virtual volume page and the capacity pool page. The storage system further includes a data compression controller operable to perform a compression operation, and a data decompression controller operable to perform a decompression operation.

FIELD OF THE INVENTION

The present invention generally relates to storage technology and more specifically to storage systems incorporating one or more compressed data volumes.

DESCRIPTION OF THE RELATED ART

Generally, it is desirable for a storage system to reduce waste of storage space on storing unnecessary and/or redundant information thereby reducing the size of the stored data. Storing only the necessary information increases the storage capacity available for storing important data thereby reducing overall storage costs. In the past, a number of approaches for reducing the size of the stored data have been developed.

One such solution includes a filesystem which is designed to automatically compress the data files that it manages. This approach is widely used in the art, for example in “Microsoft® Windows® NTFS”. While this approach is very effective, it has one critical limitation, wherein the files compressed by one filesystem cannot be used in other filesystems because of differences in implementation of different filesystems.

Another solution is “thin provisioning”, which is disclosed in U.S. Pat. No. 7,130,960, incorporated herein by reference in its entirety. The aforesaid thin provisioning technique also reduces the waste data by preventing allocation of any storage capacity to unwritten data area. This technology is applied at the block device level such that the implementation of thin provisioning is fully transparent to the filesystem. However, in many cases, thin provisioning volumes incorporate data areas filled with “0” data near the storage areas filled with useful information. Such “0”-filled data areas constitute a waste of storage capacity in the storage system.

On the other hand, low-level storage devices, such as tape drives, often incorporate a compression function. For example, a tape storage device can compress data when it transfers volume data stored in hard disk drives (HDDs) to a tape medium. But the aforesaid compression based volume data transfer is problematic when a part of the transferred data needs to be modified. To modify a part of the compressed volume data, one must first decompress the entire data volume, including unchanged data, then modify the necessary parts thereof and, finally, re-compress the entire volume again. This is because the compressed data cannot be modified directly without recompression. The aforesaid steps take long time to perform, preventing the transactional use of the data volume during the lengthy compression process. Systems using HDDs instead of tape devices suffer from the same problem as the tape medium.

Thus, the existing storage technology is deficient in its ability to effectively reduce the size of the stored data using compression and/or thin provisioning.

SUMMARY OF THE INVENTION

The inventive methodology is directed to methods and systems that substantially obviate one or more of the above and other problems associated with conventional techniques involving thin provisioning and data compression.

In accordance with one aspect of the inventive concept, there is provided a computerized data storage system. The inventive system incorporates at least one storage device having a nonvolatile writable medium; a cache memory operatively coupled to the storage port and having a data storing area and a data management controller; and a storage port. The storage port is configured to connect to a host computer and receive and send I/O information required by the host computer. The storage port is configured to receive requests to read and write data, and, in response to the request to read data, the storage port is configured to send the data stored in the data storing area of the cache memory and in response to a request to write data, the storage port is configured to send the write data to the data storing area of the cache memory. The inventive system further includes a thin provisioning controller configured to provide a virtual volume having a virtual volume page, a capacity pool having a capacity pool page and manage a mapping between the virtual volume page and the capacity pool page. The inventive system yet further includes a data compression controller configured to perform a compression operation on the virtual volume page, and a data decompression controller configured to perform a decompression operation on the virtual volume page.

In accordance with another aspect of the inventive concept, there is provided a method to be performed by a computerized data storage system. The inventive method involves: providing a virtual volume having a virtual volume page; providing a capacity pool having a capacity pool page; managing a mapping between the virtual volume page and the capacity pool page; providing a data caching area storing data; receiving a request to read data from a host computer, and, in response to the request to read data, sending to the host computer the data stored in the data caching area; receiving a request to write data from the host computer, and, in response to the request to write data, writing the write data provided by the host computer to the data caching area; performing a compression operation on the virtual volume page, and performing a decompression operation on the virtual volume page.

In accordance with yet another aspect of the inventive concept, there is provided a computer-readable medium embodying a set of instructions. The aforesaid set of instructions, when executed by a storage system comprising one or more processors, causes the storage system to: provide a virtual volume, the virtual volume comprising a virtual volume page; provide a capacity pool comprising a capacity pool page; manage a mapping between the virtual volume page and the capacity pool page; provide a data caching area storing data; receive a request to read data from a host computer, and, in response to the request to read data, send to the host computer the data stored in the data caching area; receive a request to write data from the host computer, and, in response to the request to write data, write the write data provided by the host computer to the data caching area; perform a compression operation on the virtual volume page, and perform a decompression operation on the virtual volume page.

DETAILED DESCRIPTION

Storage System Components

FIG. 1illustrates an exemplary system architecture of an embodiment of the inventive storage system. With reference toFIG. 1, an exemplary embodiment of a storage system consistent with principles of the inventive approach incorporates Storage Subsystem100, Storage Network200and Host Computer300. In one implementation, the Storage Subsystem100includes Storage Controller110, Disk Unit120and Management Terminal130. In one embodiment, the aforesaid Storage Controller110incorporates a CPU111, which executes various software programs. The programs and data tables used by the CPU111are stored in the Memory112of the Controller110. In one embodiment, the controller110further incorporates a Disk Interface114, which may be implemented as a SCSI interface. The Disk Interface114operates to connect Disk120to the Controller110. The controller110also incorporates Host Interface115, which may be implemented as a FibreChannel interface.

The Host Interface115operates to interconnect the Controller110with the Host Computer300via the Storage Network200. The Host Interface115receives I/O requests from the Host Computer300and provides the corresponding information to the CPU111. In one implementation, the Disk Controller110further incorporates Management Terminal Interface (e.g. NIC I/F)116. The Management Terminal Interface116connects the Disk Controller110with the Storage Controller Interface133. The aforesaid Management Terminal Interface116receives volume, disk and capacity pool operation requests from Management Terminal130and inform to CPU111.

The Disk Unit120incorporates one or more Disks121, which may be HDDs. The Management Terminal130may include a CPU131, which operates to manage various processes of the Management Terminal130, a Memory132and a Storage Controller Interface (NIC)133. The Storage Controller Interface133is connected to Management Terminal Interface116of the Disk Controller110. The Storage Controller Interface133sends information on the volume, disk and capacity pool operations to Storage Controller110. In one embodiment, the Management Terminal130further includes a User Interface134, which may be a Keyboard, Mouse, Monitor or the like devices.

FIG. 2illustrates an exemplary structure of the information stored in the Memory112. In one implementation, the Memory112stores a Volume Operation Program112-02. The Volume Operation Program112-02includes a Volume Operation Waiting Program112-02-1, Volume Compression Program112-02-2and Volume Decompression Program112-02-3, illustrated inFIG. 3. The Volume Operation Waiting Program112-02-1executes when the CPU111receives a volume compression or decompression request. This program may be implemented as a system residence program. The Volume Compression Program112-02-2executes when the CPU111received a volume compression request. The Volume Compression Program112-02-2changes a thin provisioning volume to a compression volume using compression. The Volume Compression Program112-02-2is called by Volume Operation Waiting Program112-02-1.

The Volume Decompression Program112-02-3executes when the CPU111receives a volume decompression request. The Volume Decompression Program112-02-3changes a compression volume to a thin provisioning (decompression) volume using decompression. The Volume Operation Program112-02-3is called by Volume Operation Waiting Program112-02-1.

In one exemplary implementation, the Memory112further stores an I/O Operation Program112-04. The I/O Operation Program112-04consists of a Write I/O Operation Program112-04-1and a Read I/O Operation Program112-04-2, illustrated inFIG. 4. The Write I/O Operation Program112-04-1executes when the CPU111receives a write I/O request. The Write I/O Operation Program112-04-1transfers I/O data from the Host Computer300to the Cache Area112-20via the Host interface115. This program112-04-1may be implemented as a system residence program.

The Read I/O Operation Program112-04-2is executed when the CPU111receives a read I/O request. The Read I/O Operation Program112-04-2operates to transfer I/O data from the Cache Area112-20to the Host Computer300. The Read I/O Operation Program112-04-2may also be implemented as a system residence program.

In one exemplary implementation, the Memory112may also store a Disk Access Program112-05. The Disk Access Program112-05includes a Disk Flushing Program112-05-1, Cache Staging Program112-05-2and a Cache Destaging Program112-05-1, illustrated inFIG. 5. The Disk Flushing Program112-05-1searches for dirty cache data and flushes it to Disk121. The Disk Flushing Program112-05-1is executed when the workload of the CPU111is relatively low. The Disk Flushing Program112-05-1may also be implemented as a system residence program.

The Cache Staging Program112-05-2operates to transfer data from Disk121to Cache Area112-05-20. The Cache Staging Program112-05-2is executed when the CPU111needs to access the data in the Disk121. The Cache Destaging Program112-05-3transfers data from the Cache Area. The Cache Destaging Program112-05-2is executed when the Disk Flushing Program112-05-1flushes dirty cache data to the Disk121.

In one exemplary implementation, the Memory112further stores Compression/Decompression Program112-06. The Compression/Decompression Program112-06includes a Compression Program112-06-1and Decompression Program112-06-2, illustrated inFIG. 6. The Compression Program112-06-1operates to compress data in the Cache Area112-20. The Compression Program112-06-1uses the Buffer Area112-21to temporarily store the compressed data. The Compression Program112-06-1is executed upon a call from the Cache Destaging Program112-05-2, when there is data that needs to be compressed. The Decompression Program112-06-2decompresses data in the Cache Area112-20and uses Buffer Area112-21to temporarily store the decompressed data. The Decompression Program112-06-2is executed upon a call from the Cache Staging Program112-05-1, when there is data that needs to be decompressed.

In one exemplary embodiment, the Memory112may further store an Encryption/Decryption Program112-07. In one implementation, the Encryption/Decryption Program112-07includes Encryption Program112-07-1and Decryption Program112-07-2, illustrated inFIG. 7. The Encryption Program112-07-1encrypts data in the Cache Area112-20. This program uses Buffer Area112-21to temporarily store the encrypted data. The Encryption Program112-07-1is executed upon a call from the Cache Destaging Program112-05-2, when there is data that needs to be encrypted.

When both Encryption Program112-07-1and Compression Program112-06-1are sequentially executed on the same data set, the Compression Program112-06-1is executed first and the Encryption Program112-07-1is executed second. The Decryption Program112-07-2decrypts data in the Cache Area112-20. This program uses Buffer Area112-21to temporarily store the decompressed data. The Decryption Program112-07-2is executed upon a call from the Cache Staging Program112-05-1, when there is data that needs to be decrypted. When both Decryption Program112-07-2and Decompression Program112-06-2are sequentially executed on the same dataset, the Decryption Program112-07-2is executed first and the Decompression Program112-06-2is executed second.

In one exemplary embodiment, the Memory112may further store a Capacity Pool Management Program112-08. The Capacity Pool Management Program112-08does garbage collection in capacity pools. The Capacity Pool Management Program112-03is executed when the workload of the CPU111is relatively low or the remaining capacity of the capacity pool is low. This program may be implemented as a system residence program.

In one exemplary embodiment, the Memory112may further store a RAID Group Management Table112-11. The aforesaid RAID Group Management Table112-11is illustrated inFIG. 8and may include a RAID Group Number Information column112-11-01representing an ID of RAID group in Storage Controller110as well as RAID Level Information column112-11-02. The information in the RAID Level Information column112-11-02carries information on the RAID level as well as RAID organization Information. The value of “10” in this column means “Mirroring and Striping”, the value “5” means “Parity Striping”, while the value “6” means “Double Parity Striping.” The value “N/A” means that the corresponding RAID group doesn't exist.

The RAID Group Management Table112-11may further include HDD Number Information column112-11-03. This column stores ID list of Disks121grouped in the corresponding RAID group. The RAID Group Management Table112-11may further include HDD Capacity Information column112-11-04, storing information on minimum capacity of the Disk121of the corresponding RAID group.

The Memory112may further store a Virtual Volume Management Table112-12. The Virtual Volume Management Table112-12is illustrated inFIG. 9and may include a Volume Number Information column112-12-01storing ID of the corresponding virtual volume in Storage Controller110. The table112-12may further include a Volume Capacity Information column112-12-02storing the information on the capacity of the respective virtual volume. The table112-12may further include a Capacity Pool Number Information column112-12-03storing a Capacity Pool Number corresponding to the respective virtual volume. Each virtual volume is allocated data storage capacity from this capacity pool. The table112-12may further incorporate the Volume Type Information column112-12-04storing virtual volume type information. The value “Thin Provisioning” in this column means that the virtual volume is a normal thin provisioning volume. “Compressed” means that the corresponding virtual volume is a thin provisioning volume having compressed pages. “Encrypted” means that the corresponding virtual volume is a thin provisioning volume having encrypted pages. “Compressed & Encrypted” means that the corresponding virtual volume is a thin provisioning volume having pages that are compressed and encrypted. Finally, “N/A” means that the corresponding virtual volume doesn't exist.

The aforesaid table112-12may further include Current Using Chunk Information column112-12-05storing information on chunks that the virtual volume has received from the respective capacity pool specified in the Capacity Pool Number Information column112-12-03. As one of ordinary skill in the art would appreciate, each virtual volume receives capacity pool pages from the pool chunk.

In one implementation, the Memory112also stores Virtual Volume Page Management Table112-13. The Virtual Volume Page Management Table112-13is illustrated inFIG. 10and may include a Virtual Volume Page Address column112-13-01specifying ID of the virtual volume page in the corresponding virtual volume. The table112-13may further include Related RAID Group Number column112-13-02specifying the RAID group number of the allocated capacity pool page. The value “N/A” in this column indicates that the virtual volume page doesn't allocate a capacity pool page.

The table112-13may further include a Capacity Pool Page Address column112-13-03storing a Logical address of the corresponding capacity pool page. And in particular the start address of the capacity pool page. The table112-13may further include Capacity Pool Page Size column112-13-04storing information on the size of the corresponding capacity pool page. If the capacity pool size is the same as the default size, it indicates that the virtual volume page isn't compressed.

In one implementation, the Memory112also stores Capacity Pool Management Table112-14. The Capacity Pool Management Table112-14is illustrated inFIG. 11and may include a Capacity Pool Number column112-14-01storing ID of the capacity pool in the Storage Controller110. The table112-14may further include a RAID Group List column112-14-02storing a list of RAID groups that are included into the capacity pool. The value “N/A” in this column means that the respective capacity pool doesn't exist. The table112-14may further include a Free Capacity Information column112-14-03storing information on storage capacity of the entire free area in the capacity pool.

In one implementation, the Memory112also stores a Capacity Pool Element Management Table112-15. The Capacity Pool Element Management Table112-15is illustrated inFIG. 12and may include a RAID Group Number column112-15-01storing an ID of the corresponding RAID group in the Storage Controller110. The table112-15may further include a Capacity Pool Number column112-15-02storing the ID of the Capacity pool that the corresponding RAID Group belongs to.

The table112-15may further include a Free Chunk Queue Index column112-15-03storing the Free chunk queue index number. In an embodiment of the inventive storage system, the RAID Group manages the free chunks as a queue. The table112-15may further include a Used Chunk Queue Index column112-15-04storing used chunk queue index number. In one embodiment of the inventive storage system, the RAID Group manages the used chunks as a queue.

In one implementation, the Memory112also stores Capacity Pool Chunk Management Table112-16. The Capacity Pool Chunk Management Table112-16is illustrated inFIG. 13and includes a Chunk Number column112-16-01storing an ID of the chunk in the RAID group. The table112-16may further include a Virtual Volume Number column112-16-02storing the number of the virtual volume that uses the capacity pool chunk.

The table112-16may further include a Used Capacity Information column112-16-03storing information on total used capacity of the capacity pool chunk. When a virtual volume gets a capacity pool page from the capacity pool chunk, this parameter is increased by the capacity pool page size.

The table112-16may further include a Deleted Capacity Information column112-16-04storing information on total deleted capacity from the capacity pool chunk. When a virtual volume releases a capacity pool page by volume format or virtual volume page reallocation, this parameter is increased by the capacity of the pool page size.

The table112-16may further include a Next Chunk Pointer column112-16-05storing a Pointer of the other capacity pool chunk. In an embodiment of the inventive storage system, the capacity pool chunks have a queue structure. The values in the Free Chunk Queue Index column112-15-03and Used Chunk Queue Index column112-15-04are the indexes of the aforesaid queue.

In one implementation of the invention, the Memory112also stores Capacity Pool Page Management Table112-17. The Capacity Pool Page Management Table112-17is illustrated inFIG. 14and includes a Capacity Pool Page Size column112-17-01storing information on the size of the corresponding capacity pool page. This parameter is stored when the capacity page is allocated to the virtual volume page. The value “N/A” in this column indicates the end of the capacity pool page list. The total size that the value in the Capacity Pool Page Size column112-17-01represents equals to sum of allocated and deleted size that is written in Used Capacity Information column112-16-03and Deleted Capacity Information column112-16-04.

The table112-17may further include a Virtual Volume Page Number column112-17-02storing virtual volume page number that corresponds to the capacity pool page. The value “NULL” in this column indicates a deleted page, when the value in the Capacity Pool Page Size column112-17-01is not “N/A”.

In one implementation of the invention, the Memory112also stores Cache Management Table112-18. The Cache Management Table112-18is illustrated inFIG. 15and includes a Cache Slot Number column112-18-01storing the ID of the cache slot in Cache Area112-20. In one implementation of the invention, the Memory112includes a Cache Area112-20, which may include multiple cache slots. The table112-18may also include a Disk Number column112-18-02storing information on the Disk121or Virtual Volume140number corresponding to the data stored in the cache slot. The value in the Disk Number column112-18-02can identify the related Disk121or Virtual Volume140.

The Disk Address column112-18-03of the table112-18stores Disk address corresponding to the data stored in the cache slot. The Next Slot Pointer column112-18-04stores a Next cache slot number. In an embodiment of the inventive system, cache slots have a queue structure. The value “NULL” in the aforesaid column indicates the end of the queue.

The Kind of Queue Information column112-18-11stores information on the type of cache slot queue. The value “Free” in this column indicates the queue that has the unused cache slots. The value “Clean” indicates a queue that incorporates cache slots that stores the same data as the disk slots. The value “Dirty” indicates a queue that incorporates cache slots that stores data different from the data stored in the disk slots. Thus, the Storage Controller110needs to flush the cache slot data to the disk slot in the future. Finally, a Queue Index Pointer column112-18-12of the table112-18stores a value of the index of the cache slot queue.

As mentioned hereinabove, the Memory112incorporates a Cache Area112-20. This area may include multiple Cache Slots112-20-1, as shown inFIG. 21. The Cache Slots112-20-1are managed by Cache Management Table112-18. The Memory112may also incorporate a Buffer Area112-21. The Buffer Area112-21provides temporary storage for work data.

Logical Structure

Now, the logical structure of the Storage Subsystem100will be described in detail.FIG. 16illustrates the relationship of the capacity pool chunk, capacity pool page and disk cache. The Capacity Pool Chunk121-1consists of plural Disk Slots121-3in a RAID group. The Capacity Pool Chunk121-1can have 0 or more Capacity Pool Pages121-2in it. In an embodiment of the invention, the size of Capacity Pool Chunk121-1is fixed. A capacity Pool Page121-2consists of plural disk slots in a RAID group. The capacity Pool Page121-2can have 1 or more Disk Slots121-3in it. In an embodiment of the invention, the size of Capacity Pool Page121-2is variable. The Disk Slot121-3represents a stripe block of the RAID structure. In an embodiment of the invention, the size of Disk Slot121-3is fixed and is the same as the Cache Slot112-20-1size. The Disk Slot stores host data or parity data.

FIG. 17illustrates the relationship of virtual volume page, virtual volume slot and virtual volume. The Virtual Volume140will now be described. The Host Computer300accesses the Virtual Volume140by means of I/O operations. The Virtual Volume140is allocated storage capacity from the capacity pool and includes one or more Virtual Volume Slots140-2. The Virtual Volume140is allocated storage resources using a Virtual Volume Page140-1. The Virtual Volume Page140-1includes one or more Virtual Volume Slots140-2. The Virtual Volume Slot140-2has the same capacity as the Cache Slot112-20-1and Disk Slot121-3.

FIG. 18illustrates the relationship of Capacity Pool Management Table112-14, Capacity Pool Element Management Table112-15, Capacity Pool Chunk Management Table112-16, RAID Group Management Table112-11and Capacity Pool Chunks121-1. Dashed line inFIG. 18indicates a reference by pointer, while the solid line indicates reference by calculation. The Capacity Pool Management Table112-14references the Capacity Pool Element Management Table112-15using RAID Group List column112-14-02. The Capacity Pool Element Management Table112-15references the Capacity pool Management Table112-14using Capacity Pool Number column112-15-02. Capacity Pool Element Management Table112-15references Capacity Pool Chunk Management Table122-16using Free Chunk Queue column112-15-03and Used Chunk Queue column112-15-04. The relationship of Capacity Pool Element Management Table112-15and RAID Group Management Table112-11is fixed. The relationship of Capacity Pool Chunk121-1and Capacity Pool Chunk Management Table112-15is also fixed.

FIG. 19illustrates the relationship of the Virtual Volume140, the Virtual Volume Page140-1, the Virtual Volume Management Table112-12, the Virtual Volume Page Management Table112-13, the Capacity Pool Management Table112-14, the Capacity Pool Chunk121-1, the Capacity Pool Page121-2and the Capacity Pool Element Management Table. In that figure, a dashed line indicates a reference by pointer, while a solid line indicates a reference by calculation.

The Virtual Volume Management Table112-12references the Capacity Pool Management Table112-14using the Capacity Pool Number Information column112-12-03. The Virtual Volume Management Table112-12references the allocated Capacity Pool Chunk121-1using Current Using Chunk Information column112-12-05. The Capacity Pool Management Table112-14references the RAID group using the RAID Group List column112-14-02. The Virtual Volume Page Management Table112-13references the Virtual Volume Page121-2using the Capacity Pool Page Address column112-13-03and Capacity Pool Page Size column112-13-04.

The relationship of the Virtual Volume140and the Virtual Volume Management Table112-12is fixed. The relationship of Virtual Volume Management Table112-12and the Virtual Volume Page Management Table112-13is also fixed. The relationship of the Virtual Volume Page140-1and the Virtual Volume Page Management Table112-13is likewise fixed.

FIG. 20illustrates the relationship of the Virtual Volume140, the Virtual Volume Page140-1, the Capacity Pool Chunk121-1, the Capacity Pool Page121-2and the Capacity Pool Element Management Table. As in the previous figures, in this figure, a dashed line indicates a reference by pointer, while a solid line indicates a reference by calculation. The Capacity Pool Chunk Management Table112-16references the Virtual Volume140using Virtual Volume Number column112-16-02. The Capacity Pool Page Management Table112-17references the Virtual Volume Page140-1using Virtual Volume Page Number column112-17-02.

In an embodiment of the inventive system, the relationship of the Capacity Pool Chunk121-1and the Capacity Pool Chunk Management Table112-16is fixed. In an embodiment of the invention, the Capacity Pool Page Management Table112-17related to Capacity Pool Page121-2is found by seeking Capacity Pool Page Management Table112-17.

FIG. 21illustrates the relationship of the Cache Slot112-20-1, the Cache Management Table112-16and the Disk Slot121-3. As in the previous figures, a dashed line indicates a reference by pointer, while a solid line indicates a reference by calculation. The Cache Management Table112-18references the Disk Slot121-3using the Disk Number column112-18-02and the Disk Address column112-18-03. In an embodiment of the invention, the relationship of Cache Management Table112-18and Cache Slot112-20-1is fixed.

Operational Flow Chart of the Storage System

FIG. 22illustrates an exemplary embodiment of an operational flow chart of the Volume Operation Waiting Program112-02-1. The Volume Operation Waiting Program112-02-1includes one or more of the following steps.

At Step112-02-1-1, the CPU111checks whether a volume operation request has been received. If it is determined that the CPU111has received the aforesaid request, the CPU111proceeds to Step112-02-1-2. If the CPU111has not received the request, the CPU111repeats the Step112-02-1-1.

At Step112-02-1-2, the CPU111checks the type of the received request. If the CPU111received a “Change to Compress Volume” request, then the CPU111proceeds to Step112-02-1-3. If the CPU111didn't receive the “Change to Compress Volume” request, then the CPU111proceeds to Step112-02-1-4.

At Step112-02-1-3, the CPU111calls Volume Compression Program112-02-2in order to compress the volume. After the completion of the Step112-02-1-3, the CPU111returns to the Step112-02-1-1.

At Step112-02-1-4, the CPU111again checks the type of the received request. If the CPU111received a “Change to Decompress Volume” request, then the CPU111proceeds to Step112-02-1-5. If the CPU111has not received the “Change to Decompress Volume” request, then the CPU111returns to the Step112-02-1-1.

At Step112-02-1-5, the CPU111calls the Volume Decompression Program112-02-3in order to decompress the volume. After the completion of the Step112-02-1-5, the CPU111returns to the Step112-02-1-1.

FIG. 23illustrates an exemplary embodiment of an operational flow chart of the Volume Compression Program112-02-2. Upon invocation of this program, it is provided with a volume number for compression. The Volume Compression Program112-02-2may include one or more of the following steps.

At Step112-02-2-1, the CPU111checks whether or not the target volume is already compressed. If the value in the Volume Type Information column112-12-04corresponding to the target volume is “Thin Provisioning” or “Encrypted” then the CPU111proceeds to Step112-02-2-2. If the corresponding value in the Volume Type Information column112-12-04is not “Thin Provisioning” or “Encrypted”, then the CPU111terminates the execution of the Volume Compression Program112-02-2.

At Step112-02-2-2, the CPU111sets the value of the virtual volume pointer to the top of the target virtual volume. Specifically, the pointer is set to the first page of the virtual volume. After that, the CPU111proceeds to Step112-02-2-6.

At Step112-02-2-6, the CPU111calls the Cache Staging Program112-05-2in order to stage the page data121referenced by the aforesaid pointer from the HDDs. After the completion of the Step112-02-2-6, the CPU111proceeds to Step112-02-2-3.

At Step112-02-2-3, the CPU111calls the Compression Program112-06-1in order to compress the page referenced by the aforesaid pointer. After the completion of the Step112-02-2-3, the CPU111proceeds to the Step112-02-2-4.

At Step112-02-2-4, the CPU111checks whether or not the pointer has reached the end page of the virtual volume. If the pointer points to the aforesaid end page, then the CPU111terminates the execution of the Volume Compression Program112-02-2. If the pointer does not point to the end page, then the CPU111proceeds to the Step112-02-2-5.

At Step112-02-2-5, the CPU111sets the pointer to point to the next page of the virtual volume.

FIG. 24illustrates an exemplary embodiment of an operational flow chart of the Volume Decompression Program112-02-3. When the aforesaid program is invoked, it is provided with a volume number to be decompressed. The Volume Decompression Program112-02-3may include one or more of the following steps.

At Step112-02-3-1, the CPU111checks whether or not the target volume has already been decompressed. If the value in the Volume Type Information column112-12-04corresponding to the target volume is “Compressed” or “Encrypted & Compressed”, then the CPU111proceeds to Step112-02-3-2. If the corresponding value in the Volume Type Information column112-12-04is not “Compressed” or “Encrypted & Compressed”, then the CPU111terminates the Volume Decompression Program112-02-3.

At Step112-02-3-2, the CPU111sets the pointer to first page of the virtual volume. Then, the CPU111proceeds to Step112-02-3-3.

At Step112-02-3-3, the CPU111decompresses the page pointed to by the pointer. To this end, the CPU111calls Decompression Program112-06-2to decompress the page. After the completion of the Step112-02-3-3, the CPU111proceeds to the Step112-02-3-4.

At Step112-02-3-4, the CPU111checks whether or not the pointer has reached the end page of the virtual volume. If it is determined that the pointer points to the end page of the virtual volume, then the CPU111terminates the Volume Compression Program112-02-3. If the pointer does not point to the end page of the virtual volume, then the CPU111proceeds to the Step112-02-3-5.

At Step112-02-3-5, the CPU111re-sets the pointer to point to the next page of the virtual volume.

FIG. 25illustrates an exemplary embodiment of an operational flow chart of the Write I/O Operation Program112-04-1. An embodiment of the Write I/O Operation Program112-04-1may include one or more of the following steps.

At Step112-04-1-1, the CPU111checks whether or not a write I/O request has been received. If CPU111determines that the request has been received, then the CPU111proceeds to Step112-04-1-2. If CPU111did not receive the request, then the CPU111repeats the Step112-04-1-1.

At Step112-04-1-2, the CPU111searches a record in the Cache Management Table112-20referenced by the “Clean” or “Dirty” queue to locate Cache Slot112-20-1of the I/O. If CPU finds the appropriate Cache Slot112-20-1, then the CPU111proceeds to Step112-04-1-4. If CPU does not find the Cache Slot112-20-1, then the CPU111proceeds to Step112-04-1-3.

At Step112-04-1-3, the CPU111obtains a Cache Slot112-20-1that is linked to the “Free” queue of the Cache Management Table112-20. After that, the CPU111proceeds to Step112-04-1-4.

At Step112-04-1-4, the CPU111transfers the write I/O data to the Cache Slot112-20-1from the Host Computer300. After that, the CPU111returns to the Step112-04-1-1.

FIG. 26illustrates an exemplary embodiment of an operational flow chart of the Read I/O Operation Program112-04-2. The exemplary embodiment of the Read I/O Operation Program112-04-2may include one or more of the following steps.

At Step112-04-2-1, the CPU111checks whether or not a read I/O request has been received. If CPU111determines that the aforesaid request has been received, then the CPU111proceeds to Step112-04-2-2. If the CPU111did not receive the request, then the CPU111repeats the Step112-04-2-1.

At Step112-04-2-2, the CPU111searches the records of the Cache Management Table112-20linked to “Clean” or “Dirty” queue to find Cache Slot112-20-1of the I/O request. If the CPU successfully finds the Cache Slot112-20-1, then the CPU111proceeds to Step112-04-1-6. If CPU could not find the Cache Slot112-20-1, then the CPU111proceeds to Step112-04-1-3.

At Step112-04-2-3, the CPU111obtains a Cache Slot112-20-1that is linked to “Free” queue of Cache Management Table112-20. After that, the CPU111proceeds to Step112-04-2-4.

At Step112-04-2-4, the CPU111finds the Capacity Pool Page121-2referenced by the Virtual Volume Page by searching the Virtual Volume Page Management Table112-13. After that, the CPU111proceeds to Step112-04-2-5.

At Step112-04-2-5, the CPU111invokes the Cache Staging Program112-05-2in order to transfer the data from the Disk Slot121-3to the Cache Slot112-20-1. After the completion of the Step112-04-2-5, the CPU111proceeds to Step112-04-2-6.

At Step112-04-2-6, the CPU111transfers the read I/O data from the Cache Slot112-20-1to the Host Computer300. After that, the CPU111returns to the Step112-04-2-1.

FIG. 27illustrates an exemplary embodiment of an operational flow chart of the Cache Staging Program112-05-2. When this program is invoked, it is provided with a staging (transfer from disk to cache memory) slot information. The Cache Staging Program112-05-2may include one or more of the following steps.

At Step112-05-2-1, the CPU111checks whether or not the page has been compressed. If the value in the Capacity Pool Page Size column112-13-04indicates a default page size, the CPU111determines that that the page has been compressed. If the page has been compressed, then the CPU111proceeds to Step112-05-2-5. If the page has not been compressed, then the CPU111proceeds to Step112-05-2-2.

At Step112-05-2-2, the CPU111transfers the slot data from the Disk Slot121-3to the Cache Slot112-20-1. After that, the CPU111proceeds to Step112-05-2-3.

At Step112-05-2-3, the CPU111checks whether or not the page has been encrypted. Specifically, if the corresponding value in the Volume Type Information column112-12-04is “Encrypted” or “Encrypted & Compressed”, then the CPU111determines that the page has been encrypted. If the page has been encrypted, then the CPU111proceeds to Step112-05-2-4. If the page has not been encrypted, then the CPU111terminates the Cache Staging Program112-05-2.

At Step112-05-2-4, the CPU calls the Decryption Program112-07-2in order to decrypt the slot. After the completion of the Step1112-05-2-4, the CPU111terminates the Cache Staging Program112-05-2.

At Step112-05-2-5, the CPU111searches the Cache Management Table112-18for the Cache Slots112-20-1of the page that the slot belongs to, and the CPU111obtains cache slots for the slots that are not in the Cache Management Table112-18. After that, the CPU111transfers all slots of the page that the slot belongs to from Disk Slots121-3to Cache Slot112-20-1. After that, the CPU111proceeds to the Step112-05-2-6.

At Step112-05-2-6, the CPU111checks whether or not the page has been encrypted. If the value in the corresponding Volume Type Information column112-12-04is “Encrypted” or “Encrypted & Compressed”, then the CPU111determines that the page has been encrypted. If the page has been encrypted, then the CPU111proceeds to Step112-05-2-7. If the page has not been encrypted, then the CPU111terminates the Cache Staging Program112-05-9.

At Step112-05-2-7, the CPU111invokes the Decryption Program112-07-2in order to decrypt the page that the slot belongs to. After the completion of the Step1112-05-2-4, the CPU111proceeds to Step112-05-2-8.

At Step112-05-2-8, the CPU111calls the Decompression Program112-06-2in order to decompress the page that the slot belongs to. After the completion of the Step1112-05-2-8, the CPU111terminates the Cache Staging Program112-05-2.

FIG. 28illustrates an exemplary embodiment of an operational flow chart of the Decompression Program112-06-2. Upon its invocation, the Decompression Program112-06-2is provided with a page for decompression. The Decompression Program112-06-2may include one or more of the following steps.

At Step112-06-2-1, the CPU111reads the Cache Slots112-20-1of the page. After that, the page is being decompressed and stored in the Buffer Area112-21. Then, the CPU111proceeds to Step112-06-2-2.

At Step112-06-2-2, the CPU111sets a pointer to the first slot number of the decompressed page in Buffer Area112-21. After that, the CPU111proceeds to Step112-06-2-3.

At Step112-06-2-3, the CPU111searches the Cache Management Table112-18and determines whether the Virtual Volume140has a Cache Slot112-20-1that relates to the decompressed slot. If the Virtual Volume140has a Cache Slot112-20-1that relates to the decompressed slot, then the CPU proceeds to Step112-06-2-4. If the Virtual Volume140does not have a Cache Slot112-20-1that relates to the decompressed slot, then the CPU111proceeds to Step112-06-2-5.

At Step112-06-2-4, the CPU111transfers the decompressed slot from the Buffer Area112-21to the related Cache Slot112-20-1of the Virtual Volume Slot140-2. After that, the CPU111proceeds to Step112-06-2-5.

At Step112-06-2-5, the CPU111determines whether the pointer reached the last slot of the decompressed page in the Buffer Area112-21. If the pointer has reached the last slot, then the CPU111terminates the Decompress Program112-06-2. If the pointer has not reached the last slot, then the CPU111proceeds to Step112-06-2-6.

At Step112-06-2-6, the CPU111sets the pointer to the next slot. After that, the CPU111returns to Step112-06-2-3.

FIG. 29illustrates an exemplary embodiment of an operational flow chart of the Decryption Program112-07-2. When the program is invoked, it is provided with a slot for decryption. The Decryption Program112-07-2may include one or more of the following steps.

At Step112-07-2-1, the CPU111reads the Cache Slot112-20-1of the Disk Slot121-3, decrypts the page, and stores it in the Buffer Area112-21. After that, the CPU111proceeds to Step112-07-2-2.

At Step112-07-2-2, the CPU111copies the decrypted slot in Buffer Area112-21to the Cache Slot112-20-1of the Virtual Volume Slot121-3. After that, the CPU111terminates the Decryption Program112-07-2.

FIG. 30illustrates an exemplary embodiment of an operational flow chart of the Disk Flushing Program112-05-1. The Disk Flushing Program112-05-1may include one or more of the following steps.

At Step112-05-1-1, the CPU111searches “Dirty” queue of Cache Management Table112-18and obtains the first slot of the queue. After that, the CPU111proceeds to Step112-05-1-2.

At Step112-05-1-2, the CPU calls the Cache Destaging Program112-05-3. After the completion of the Step112-05-1-2, the CPU111returns to Step112-05-1-1.

FIGS. 31 and 32illustrate exemplary embodiments of an operational flow charts of the Cache Destaging Program112-05-3. Upon invocation of this program, it is provided with a destaging (transfer to cache memory from disk) slot. In one embodiment of the invention, the Cache Destaging Program112-05-3may include one or more of the following steps.

At Step112-05-3-1, the CPU111checks whether or not the page of the slot needs to be compressed. If the corresponding value in the Volume Type Information column112-12-04is “Compressed” or “Encrypted & Compressed”, the CPU111determines that the page of the slot needs to be compressed. If the page of the slot needs to be compressed, then the CPU111proceeds to Step112-05-3-5. If the page of the slot does not need to be compressed, then the CPU111proceeds to Step112-05-3-2.

At Step112-05-3-2, the CPU111checks the Virtual Volume Page Management Table112-13to determine whether or not the page of the slot has already been allocated. If the page has already been allocated, then the CPU111proceeds to Step112-05-3-12. If the page has not been allocated yet, then the CPU111proceeds to Step112-05-3-3.

At Step112-05-3-3, the CPU111reads the record in the Capacity Pool Page Management table112-17that is referenced by the Current Using Chunk Information112-12-05. After that, the CPU111registers the Virtual Volume Page140-1into the Current Using Chunk Information112-12-05. The size of the virtual volume page is determines by the value of the Virtual Volume Page140-1record. If the free area of the Virtual Volume Page140-1that Current Using Chunk Information112-12-05refers to is less than Virtual Volume Page140-1size, then the CPU111links this Virtual Volume Page140-1to “Used Chunk Queue” of Capacity Pool Element Management Table112-15, and obtains a new one form the “Free Chunk Queue”. After that, the CPU111registers the Capacity Pool Page121-2into the Virtual Volume Page Management table112-13. The size of the page is determined by the corresponding value in the Virtual Volume Page140-1record. After that, the CPU111proceeds to Step112-05-3-4.

At Step112-05-3-4, the CPU111fills the Disk Slot121-3of the newly allocated page with “0” data in order to format the page, except for page areas having existing data stored therein. After that, the CPU111proceeds to Step112-05-3-5.

At Step112-05-3-5, the CPU111checks Virtual Volume Page Management Table112-13to determine whether or not the page of the slot has already been allocated. If the page has already been allocated, then the CPU111proceeds to Step112-05-3-8. If the page has not been allocated yet, then the CPU111proceeds to Step112-05-3-6.

At Step112-05-3-6, the CPU111fills the Cache Slot112-20-1of Virtual Volume Page140-1with “0” data, except for areas having existing data stored therein. After that, the CPU111proceeds to Step112-05-3-7.

At Step112-05-3-7, the CPU111invokes the Compression Program112-06-1in order to compress the Virtual Volume Page140-1. After the completion of the Step112-05-3-7, the CPU111proceeds to Step112-05-3-11.

At Step112-05-3-8, the CPU111calls the Cache Staging Program112-05-2to stage and merge the page. After the completion of the Step112-05-3-8, the CPU111proceeds to Step112-05-3-9.

At Step112-05-3-9, the CPU111calls the Compression Program112-06-1in order to compress the Virtual Volume Page140-1. After the completion of the Step112-05-3-9, the CPU111proceeds to Step112-05-3-10.

At Step112-05-3-10, the CPU111dis-enrolls the current allocated Capacity Pool Page121-2from Virtual Volume Page Management Table112-13and dis-enrolls the current allocated Virtual Volume Page140-1from Capacity Pool Page Management Table112-17and appropriately increases the Deleted Capacity Information112-16-04. After that, the CPU111proceeds to Step112-05-3-11.

At Step112-05-3-11, the CPU111registers the Virtual Volume Page140-1into the Current Using Chunk Information112-12-05. The size of the registered page is the compressed page size. If the free area of Virtual Volume Page140-1that Current Using Chunk Information112-12-05refers is less than Virtual Volume Page140-1size, CPU111links this Virtual Volume Page140-1to “Used Chunk Queue” of Capacity Pool Element Management Table112-15, and obtains a new one form “Free Chunk Queue”. After that, the CPU111registers Capacity Pool Page121-2into Virtual Volume Page Management table112-13. The size of the registered page is the compressed page size. After that, the CPU111proceeds to Step112-05-3-4and Step112-05-3-12.

At Step112-05-3-12, the CPU111checks whether or not the page of the slot needs to be encrypted. If the corresponding value in the Volume Type Information column112-12-04is “Encrypted” or “Encrypted & Compressed”, then the CPU111determines that the page of the slot needs to be encrypted. If the page of the slot needs to be encrypted, then the CPU111proceeds to Step112-05-3-13. If the page of the slot doesn't need to be encrypted, then the CPU111proceeds to Step112-05-3-14.

At Step112-05-3-13, the CPU111calls the Encrypt Program112-06-1to encrypt the slot(s). After the completion of the Step112-05-3-8, the CPU111proceeds to Step112-05-3-14.

At Step112-05-3-14, the CPU111checks whether or not the slots are needed to make parity data. If the RAID Level Information is “5” or “6”, the CPU111determines that the slots are needed to make parity data. If it is determined that the slots are needed to make parity data, then the CPU111proceeds to Step112-05-3-15. If the slots are not needed to make parity data, then the CPU111proceeds to Step112-05-3-16.

At Step112-05-3-15, the CPU111makes parity data from Disk Slots121-3in the same stripe line, and stores the parity data in Cache Slot112-20-1. After that, the CPU111proceeds to Step112-05-3-16.

At Step112-05-3-16, the CPU111transfers Cache Slots112-20-1to Disk Slots121-3(if the disks are arranged in a RAID1configuration, the CPU111transfers the Cache Slots112-20-1to two Slots121-3), and after the transfer, the CPU111links the Cache Slots112-20-1to the “Clean” queue of Queue Index Pointer column112-18-12. After that, the CPU111terminates the Destaging Program112-05-3.

FIG. 33illustrates an exemplary embodiment of an operational flow chart of the Compression Program112-06-1. Upon invocation, the Compression Program112-06-1is provided with a page for compression. The Compression Program112-06-1may include one or more of the following steps.

At Step112-06-1-1, the CPU111reads the Cache Slots112-20-1of the page, compresses the page, and stores the compressed page in the Buffer Area112-21. Additionally, the compressed page includes a compression management information, for example, compression dictionary information and check sum information. After that, the CPU111proceeds to Step112-06-1-2.

At Step112-06-1-2, the CPU111sets the pointer to a first slot number of the compressed page in the Buffer Area112-21. After that, the CPU111proceeds to Step112-06-1-6.

At Step112-06-1-6, the CPU111compares the compressed data size and the virtual volume page size. If the size of the compressed data is equal or larger than the virtual volume size, then the CPU111proceeds to Step112-06-1-7, otherwise the CPU111proceeds to Step112-06-1-3.

At Step112-06-1-7, the CPU111copies the source page data in the Cache Slots112-20-1and overwrites the Buffer Area112-21. After that, the CPU111proceeds to Step112-06-1-3.

At Step112-06-1-3, the CPU111transfers the compressed slot from Buffer Area112-21to Cache Slot112-20-1of Capacity Pool Slot121-3. After that, the CPU111proceeds to Step112-06-1-4.

At Step112-06-1-4, the CPU111determines whether the pointer has reached the last slot of the compressed page in the Buffer Area112-21. If the pointer has reached the last slot, then the CPU111terminates the Compress Program112-06-1. If the pointer has not reached the last slot, then the CPU111proceeds to Step112-06-1-5.

At Step112-06-1-5, the CPU111sets the pointer to the next slot. After that, the CPU111returns to Step112-06-1-3.

FIG. 34illustrates an exemplary embodiment of a flow chart of the Encryption Program112-07-1. Upon invocation, the Encryption Program112-07-1is provided with a slot for decryption. In one embodiment, the Encryption Program112-07-1includes one or more of the following steps.

At Step112-07-1-1, the CPU111reads the Cache Slot112-20-1of the Virtual Volume Slot140-2, encrypts the page, and stores the encrypted page in the Buffer Area112-21. After that, the CPU111proceeds to Step112-07-1-2.

At step112-07-1-2the CPU111copies the encrypted slot in Buffer Area112-21to the Cache Slots112-20-1of the Disk Slot121-3. After that, the CPU111terminates the Decryption Program112-07-1.

FIG. 35illustrates an exemplary embodiment of a flow chart of the Capacity Pool Management Program112-08. The Capacity Pool Management Program112-08may include one or more of the following steps. At Step112-08-1, the CPU111searches for the records of the Capacity Pool Chunk Management Table112-16that are linked to the “Used Chunk” queue indexed by Capacity Pool Element Management Table112-15. The CPU111seeks the Deleted Capacity Information112-16-04and checks whether the respective value is more than 0, upon which the CPU111labels this chunk as “partially deleted chunk”. If the CPU111finds the “partially deleted chunk”, then the CPU111proceeds to Step112-08-2. If the CPU111does not find the “partially deleted chunk” then the CPU111returns to Step112-08-1.

At Step112-08-2, the CPU111obtains the Capacity Pool Chunk Management Table112-16records that are linked to “Free Chunk” queue indexed by the Capacity Pool Element Management Table112-15to allocate new Capacity Pool Chunk121-1. After that, the CPU111proceeds to Step112-08-3.

At step112-08-3, the CPU111sets the pointer A to first slot of the current allocated chunk and sets the pointer B to first slot of the newly allocated chunk. Thereafter, the CPU111proceeds to Step112-08-4.

At Step112-08-4, the CPU111determines whether or not the slot is in the deleted page of the chunk. To this end, the CPU111reads the Capacity Pool Page Management Table112-17. After that, the CPU111calculates page offset by sum of Capacity Pool Page Size112-17-1and checks the parameter of Virtual Volume Page Number112-17-02. If the parameter of Virtual Volume Page Number112-17-02is “NULL” then the CPU111proceeds to112-08-6. If the parameter of Virtual Volume Page Number112-17-02is not “NULL” then the CPU111proceeds to step112-08-5.

At Step112-08-5, the CPU111copies the data from the slot indicated by the pointer A to the slot indicated by the pointer B. The CPU111sets the pointer B to point to the next slot of the newly allocated chunk. After that, the CPU111proceeds to Step112-08-6.

At Step112-08-6, the CPU111checks the pointer A. If the pointer A has reached to the last slot of the current chunk, then the CPU111proceeds to Step112-08-8. If pointer A has not reached to last slot of the current chunk, then the CPU111proceeds to Step112-08-7.

At Step112-08-7, the CPU111sets the pointer A to the next slot of the current chunk. After that, the CPU111returns to Step112-08-4.

At Step112-08-8, the CPU111changes the Virtual Volume Page140-1addresses to the slots data copied from the Capacity Pool Page Management Table112-17. The CPU111also changes Virtual Volume Page Management table to newly copied Capacity Pool Page121-1addresses and sizes. After that, the CPU111proceeds to Step112-08-9.

Finally, at Step112-08-9, the CPU111sets the current chunk to “Free Chunk” queue indexed by the Capacity Pool Element Management Table112-15to allocate new Capacity Pool Chunk121-1. After that, the CPU111returns to Step112-08-1.

Exemplary Computer Platform

FIG. 36is a block diagram that illustrates an embodiment of a computer/server system3600upon which an embodiment of the inventive methodology may be implemented. The system3600includes a computer/server platform3601, peripheral devices3602and network resources3603.

The computer platform3601may include a data bus3604or other communication mechanism for communicating information across and among various parts of the computer platform3601, and a processor3605coupled with bus3601for processing information and performing other computational and control tasks. Computer platform3601also includes a volatile storage3606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus3604for storing various information as well as instructions to be executed by processor3605. The volatile storage3606also may be used for storing temporary variables or other intermediate information during execution of instructions by processor3605. Computer platform3601may further include a read only memory (ROM or EPROM)3607or other static storage device coupled to bus3604for storing static information and instructions for processor3605, such as basic input-output system (BIOS), as well as various system configuration parameters. A persistent storage device3608, such as a magnetic disk, optical disk, or solid-state flash memory device is provided and coupled to bus3601for storing information and instructions.

Computer platform3601may be coupled via bus3604to a display3609, such as a cathode ray tube (CRT), plasma display, or a liquid crystal display (LCD), for displaying information to a system administrator or user of the computer platform3601. An input device3610, including alphanumeric and other keys, is coupled to bus3601for communicating information and command selections to processor3605. Another type of user input device is cursor control device3611, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor3604and for controlling cursor movement on display3609. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

An external storage device3612may be connected to the computer platform3601via bus3604to provide an extra or removable storage capacity for the computer platform3601. In an embodiment of the computer system3600, the external removable storage device3612may be used to facilitate exchange of data with other computer systems.

The invention is related to the use of computer system3600for implementing the techniques described herein. In an embodiment, the inventive system may reside on a machine such as computer platform3601. According to one embodiment of the invention, the techniques described herein are performed by computer system3600in response to processor3605executing one or more sequences of one or more instructions contained in the volatile memory3606. Such instructions may be read into volatile memory3606from another computer-readable medium, such as persistent storage device3608. Execution of the sequences of instructions contained in the volatile memory3606causes processor3605to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor3605for execution. The computer-readable medium is just one example of a machine-readable medium, which may carry instructions for implementing any of the methods and/or techniques described herein. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device3608. Volatile media includes dynamic memory, such as volatile storage3606. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise data bus3604. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor3605for execution. For example, the instructions may initially be carried on a magnetic disk from a remote computer. Alternatively, a remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system3600can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on the data bus3604. The bus3604carries the data to the volatile storage3606, from which processor3605retrieves and executes the instructions. The instructions received by the volatile memory3606may optionally be stored on persistent storage device3608either before or after execution by processor3605. The instructions may also be downloaded into the computer platform3601via Internet using a variety of network data communication protocols well known in the art.

The computer platform3601also includes a communication interface, such as network interface card3613coupled to the data bus3604. Communication interface3613provides a two-way data communication coupling to a network link3614that is connected to a local network3615. For example, communication interface3613may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface3613may be a local area network interface card (LAN NIC) to provide a data communication connection to a compatible LAN. Wireless links, such as well-known 802.11a, 802.11b, 802.11g and Bluetooth may also used for network implementation. In any such implementation, communication interface3613sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link3613typically provides data communication through one or more networks to other network resources. For example, network link3614may provide a connection through local network3615to a host computer3616, or a network storage/server3617. Additionally or alternatively, the network link3613may connect through gateway/firewall3617to the wide-area or global network3618, such as an Internet. Thus, the computer platform3601can access network resources located anywhere on the Internet3618, such as a remote network storage/server3619. On the other hand, the computer platform3601may also be accessed by clients located anywhere on the local area network3615and/or the Internet3618. The network clients3620and3621may themselves be implemented based on the computer platform similar to the platform3601.

Local network3615and the Internet3618both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link3614and through communication interface3613, which carry the digital data to and from computer platform3601, are exemplary forms of carrier waves transporting the information.

Computer platform3601can send messages and receive data, including program code, through the variety of network(s) including Internet3618and LAN3615, network link3614and communication interface3613. In the Internet example, when the system3601acts as a network server, it might transmit a requested code or data for an application program running on client(s)3620and/or3621through Internet3618, gateway/firewall3617, local area network3615and communication interface3613. Similarly, it may receive code from other network resources.

The received code may be executed by processor3605as it is received, and/or stored in persistent or volatile storage devices3608and3606, respectively, or other non-volatile storage for later execution. In this manner, computer system3601may obtain application code in the form of a carrier wave.

It should be noted that the present invention is not limited to any specific firewall system. The inventive policy-based content processing system may be used in any of the three firewall operating modes and specifically NAT, routed and transparent.