US20010001872A1

US20010001872A1 - Data caching with a partially compressed cache

Info

Publication number: US20010001872A1
Application number: US09/090,028
Authority: US
Inventors: Shanker Singh; Joe-Ming Cheng; Brent Cameron Beardsley; Dell Patrick Leabo; Forrest Lee Wade; Michael Thomas Benhase; Marc Ethan Goldfeder
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-06-10
Filing date: 1998-06-10
Publication date: 2001-05-24
Anticipated expiration: 2018-06-10
Also published as: US6324621B2

Abstract

Aspects for caching storage data include partitioning a storage cache to include a compressed data partition and an uncompressed data partition, and adjusting a size of the compressed data partition and the uncompressed data partition for chosen performance characteristics. A data caching system aspect in a data processing system having a host system in communication with a storage system includes at least one storage device and at least one partially compressed cache. The at least one partially compressed cache further includes an uncompressed partition and a compressed partition, where the compressed partition stores at least a victim data unit from the uncompressed partition.

Description

FIELD OF THE INVENTION

The present invention relates generally to storage caches, and more particularly to partially compressed storage caches.

BACKGROUND OF THE INVENTION

As processing speeds of computer systems continue to increase, the ability to efficiently retrieve data from memory remains vital. The use of memory caches has been effective in compensating for speed mismatches between two levels of storage access, e.g., between a processor and main memory. Caches generally provide higher speed memory storage for recently/frequently used data in a computer system.

Improving the performance and utilization of caches remains an important aspect of computer system design. Typically, cache organizations and algorithms attempt to utilize the spatial and temporal localities of the storage access. Success in caches is usually measured by the hit ratio (i.e., the number of times that the needed data is found in the cache), as well as average access time (i.e., average time to locate and retrieve a piece of information and return it for processing), maximal throughput (i.e., maximal rate of data transfer), etc. At times, attempts to achieve better performance involve changes to the cache organization, which often improve hit ratios and access times at a slight expense of the maximal throughput due to cache replacing overhead.

For example, one typical method of improving performance by increasing the hit ratio involves expanding the size of the cache. Unfortunately, as the cache size is increased, an equivalent increase in the hit ratio percentage is not always achieved. For example, doubling a 4 GB (gigabytes) cache with a 75% hit ratio to 8 GB does not result in a doubling of the hit ratio. While a small percentage of improvement in the hit ratio occurs, the doubling in size results in considerable cost expenses.

Alternatively, with a fully compressed cache, an increase in storage capacity is achieved without increasing the cache size. When the compressed cache is used in a read-only environment, normally few problems in data integrity result. However, when used in an environment of changing data, significant problems result, mainly due to the need to have random access to the compressed data in the cache. Forming smaller, uniform-sized chunks within the compressed cache is sometimes used to allow more random access to portions of data. However, further complications in updating are created, since the compressed data may not elegantly fit within each chunk due to the size variations in the data. Further, compressing small chunks usually result in lower compression.

Accordingly, a need exists for a cache organization and algorithm that achieves results at least as effective as increasing a cache's size without the concomitant expense incurred by size increases.

SUMMARY OF THE INVENTION

The present invention meets these needs through a partially compressed cache organization. A method aspect for caching storage data includes partitioning a storage cache to include a compressed data partition and an uncompressed data partition, and adjusting the compressed data partition and the uncompressed data partition for chosen performance characteristics, including overall cache size. A data caching system aspect in a data processing system having a host system in communication with a storage system includes at least one storage device and at least one partially compressed cache. The at least one partially compressed cache further includes an uncompressed partition and a compressed partition, where the compressed partition stores at least a victim data unit from the uncompressed partition.

With the present invention, alternative caching organizations and algorithms are introduced that allow for dynamically adjusting partition sizes of uncompressed and compressed cache data according to hit-ratio, response time, compression ratios, and throughput (max IO) objectives. Further, the utilization of sub-partitioning a cache in order to achieve a partially compressed cache is readily applicable in multi-level caching of storage subsystems. In addition, the partially compressed cache organization achieves improved performance on par with increasing a cache's size without incurring the cost expense of cache size increase. These and other advantages of the aspects of the present invention will be more readily understood in conjunction with the following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a data processing system arrangement that utilizes caching in accordance with the present invention. [0009]
FIGS. 2 and 3 present performance modeling results that illustrate response time changes and maximum IO values with varying levels of compression of the storage cache of FIG. 1. [0010]
FIG. 4 illustrates an alternate arrangement of the system of FIG. 1 that realizes significant bandwidth advantages through the use of partial cache compression. [0011]
FIG. 5([0012] a) illustrates a block diagram of typical multi-level caching.
FIG. 5([0013] b) illustrates a multi-level caching arrangement in accordance with a further aspect of the present invention.

DESCRIPTION OF THE INVENTION

The present invention relates to partially compressed data caching. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein. [0014]
FIG. 1 illustrates a block diagram of a data processing system arrangement that utilizes caching in accordance with the present invention. Included as a part of the system are a [0015] host system 10, e.g., a central processing unit (CPU), storage cache 12, and storage (DASD, direct access storage device) 14. As in typical similar arrangements, storage cache 12 is used to provide quicker access to storage data than storage 14, e.g., on the order of microseconds per access, rather than milliseconds. In contrast to typical caching arrangements, however, the storage cache 12 in accordance with the present invention optimizes cache organization and algorithms dynamically to achieve maximum performance without requiring additional storage cache. It should be appreciated that although the discussion focuses primarily on storage controller cache applications, the invention is equally applicable to CPU cache and other caching applications, as is well appreciated by those skilled in the art.
Through the present invention, storage cache [0016] 12 is partitioned into at least two partitions, partition L3 and partition L4. Preferably, one partition, e.g., partition L3, stores uncompressed data, while a second partition, e.g., partition L4, stores compressed data. Suitably then, a compressor unit 16 and decompressor unit 18 are also included in the system of FIG. 1. For illustrative purposes, partitions L3 and L4 are shown as distinct partitions in the storage cache 12. However, this is demonstrative of the logical appearance of the partitions. In a preferred embodiment, the partitions L3 and L4 are part of the same physical memory, so that compressed and uncompressed data are intermingled in the storage cache 12.
By way of example, with a compression ratio of about 3:1, and storage cache [0017] 12 having a total size of 4 GB, partitioning the storage cache 12 into two partitions of 2 GB each results in a logical size of 8 GB for storage cache 12 (2 GB uncompressed and 2 GB compressed to store 6 GB worth of data). The partition L3 suitably stores the 2 GB of uncompressed data (unit) lines, while the partition L4 stores the 2 GB of compressed data (unit) lines. For purposes of this disclosure, a “line” suitably refers to a line cache replacement unit (or a replaceable data unit) in a cache. Thus, for storage cache 12, a cache line suitably refers to a storage device 14 record, track, or a fraction of a track.
With partitions L[0018] 3 and L4 occupying the same storage cache 12, preferably a L3 and L4 cache directory 19 tracks the status of compressed and uncompressed locations/data blocks within the storage cache 12 by storing a listing of the uncompressed blocks and a listing of compressed blocks, with the formation and updating of the directory achieved according to methods well understood by those skilled in the art. Of course, the listings could be provided as two separate directories, and a third directory (not shown) may also be included to store a listing of empty blocks, if desired.
In terms of data flow in the storage cache [0019] 12, preferably partition L3 stores data that is changing. When new data is added to partition L3, preferably a least recently used (LRU) algorithm is employed to make room for the new data by removing the least recently used data, which takes advantage of the storage access temporal locality and determines which uncompressed line becomes the removed data/victim line, as is well-known to those skilled in the art. Suitably, the victim data unit, i.e., victim line of a record, track, or fraction of a track, of partition L3 is compressed through compressor unit 16 and written to the same location in the storage cache 12. With the victim line of partition L3 compressed and stored in partition L4, the original uncompressed location now stores the compressed line and opens two empty compressed blocks in the storage cache 12. Directory 19 is suitably updated to indicate the change in status of the block from uncompressed (i.e., part of partition L3) to compressed (i.e., part of partition L4). The uncompressed victim line is also preferably written/destaged to storage 14. If L3 and L4 are provided as separate physical memory devices, and the L4 physical distance and interface is different than L3, then compressed data to L4 is physically moved to the empty slot in L4, and the directory of L4 stored in L3 or L4 is appropriately updated.
The exact compressed data size is usually unpredictable. Within a class of data type and application, the compressed size statistics are usually fairly stable. Varying methods exist for estimating space allocation for partition L[0020] 4 (e.g., for a victim line from partition L3 or for prefetched data from storage 14). A compression sniffer 20 is useful for trail compression for a data line which has been seen once. Suitably, a sniffer is a device and/or software routine that monitors data lines as they are transferred through the caching system, i.e., that monitors the ‘trail’ the data lines travel, to identify how the data lines are compressed. Thus, the compression sniffer/trail compression unit 20 suitably gives actual compressed size. If a compression sniffer is not available, alternative methods for estimating space allocation include: assigning enough space to hold the worst case expanded data (e.g., 1.125 times the line size), storing the compressed data, and reclaiming the left over space; allocating space based on a priori compression statistics, e.g., using 2 sigma the compression statistics (or other threshold) for allocation and keeping the overflow if compressed size is exceeded; or assigning the threshold (e.g., about 3:1) and merely dropping the compressed data if it does not fit (with the assumption that the data is destaged to DASD).
Partition L[0021] 4 suitably uses a LRU replacement policy and compression weighted replacement (CWR) to determine its victim lines, which takes into account that data that is directly interpretable by human and machine usually compresses well and that data that can be compressed moderately well has a higher chance of being reused than data that does not compress well. The victim line of partition L4 may suitably be discarded/removed via a bit discarder mechanism 24, i.e., a ‘bit bucket’ or universal data sink, to make space in the storage cache 12 when new data is written to partition L4.
When a read attempt results in a read miss in partition L[0022] 3 with a read hit in partition L4, partition L4 suitably passes the uncompressed line (decompressed through decompressor unit 18) to partition L3 and to the host system 10. The partition L4 entry for that line suitably becomes invalidated. When a miss occurs in both partitions L3 and L4, suitably the requested data is read back from storage 14 to the partition L3 for transfer to host system 10.
Commonly, the source block size is 512 Bytes or 1024 Bytes and a cache line, i.e., 2K or 4K Bytes, track, or half track, consists of multiple blocks, with a read or modify write to a specific block in a cache line done through the partition L[0023] 3. However, a performance penalty may result if a read or modify write occurs to a specific block that is kept in the partition L4. The primary impacts are the extra reads and writes between L3 and L4 which consumes additional data bandwidth. Preferably, therefore, when the input block size is 1.5K, 2.0K Bytes or greater, the cache line contains only a single block. In this manner, more cache lines are able to be kept in partition L4, resulting in less transfers between partitions L3 and L4. For an adaptive compression algorithm, a block size of 2KB allows a good compression region (i.e., about 3.0), since a block size of 512 B usually achieves less than 2.0 compression.
In addition to LRU replacement, the compression ratio, i.e., the ratio of uncompressed size/compressed size, is a factor in the cache replacement algorithm. Thus, the compression factor acts as a discrimination factor for cache replacement (the term discrimination factor being known commonly in Pattern Recognition (PR) research), with the objectives of the caching algorithm being a classification process that keeps the class of most useful data in the cache through some discrimination process (as less well-compressed data usually is used less often). [0024]
Suitably, the size of partitions L[0025] 3 and L4 are adjusted according to cache size, storage device size, compression/decompression hardware speed, and performance objectives, e.g., access time, response time, maximum rate of input and output required (MAX IO requirements), etc. With the use of dynamic partitioning, the storage cache 12 of the present invention realizes significant advantages over straight caching. FIGS. 2 and 3 present performance modeling results that illustrate response time changes and maximum IO values as adjustments are made to the percentage of the storage cache 12 that is compressed. The performance model of FIG. 2 suitably illustrates a storage cache 12 of size 4 GB, while the performance model of FIG. 3 suitably illustrates a storage cache 12 of size 8 GB, both used with a storage 14 of 360 GB and a compression ratio of about 3:1.
With reference to FIG. 2, when the entire storage cache [0026] 12 is used for uncompressed data storage, i.e., the partition L3 comprises 100% and the partition L4 comprises 0% of the storage cache 12, the base response time (BASE RT) is 2.9 ms (milliseconds) with a maximum IO per second (MAX IO) of 9830. With L3 at 75% and L4 at 25%, the response time is 2.8 ms, and the maximum 10 is 10530. With L3 at 50% and L4 at 50%, the response time drops to 2.6 ms, and the maximum IO is 11190. With L3 at 25% and L4 at 75%, the response time is 2.5 ms, and the maximum IO is 10620.
With reference to FIG. 3, when L[0027] 3 is 100%, and L4 is 0%, i.e., all 8 GB are uncompressed, response time is 2.7 ms and maximum IO is 10770. As the percentage changes, i.e., partition L3 goes from 75% to 50% to 25% and while partition L4 goes from 25% to 50% to 75%, the response time is 2.2 ms and the maximum IO decreases from 13590 to 13440 to 13020. The results of performance modeling, as illustrated in FIGS. 2 and 3, reveals that the partitioning of a 4 GB storage cache into two partitions of equal percentage for uncompressed and compressed data (i.e., FIG. 2, (c)) provides better response time and maximum 10 than an 8 GB storage cache with 100% uncompressed data (i.e., FIG. 3, (a)). For these conditions, the response time for the 4 GB arrangement is 2.6 ms with a maximum IO of 11190, while the response time for the 8 GB arrangement is 2.7 ms with a maximum of 10770. Thus, the 50% partitioning approach provides even better performance gains for a 4 GB cache than merely doubling the size to 8 GB with no compression would. FIGS. 2 and 3 further reveal that the most beneficial partition percentages are dependent on cache size. Thus, for the 4 GB cache, a 50% L3 and 50% L4 partitioning provides overall optimum performance. Contrastly, for the 8 GB cache, a 75% L3 and 25% L4 partitioning provides overall optimum performance.
Improvements in performance that realizes significant bandwidth advantages through the use of the partitions L[0028] 3 and L4 is achieved with an alternate arrangement of the system of FIG. 1, as illustrated in FIG. 4. In this alternate embodiment, a system 50 interfaces with a storage subsystem 52 via a system adapter 54. The system adapter 54 suitably includes compressor logic 56 and decompressor logic 58. Further included is storage cache 60 and storage 62 (e.g., DASD). Preferably, partition L3 of storage cache 60 includes a plurality of ‘home areas’, where each ‘home area’ refers to an uncompressed data block, as described with reference to FIG. 1. However, in contrast to the preferred embodiment, the system adapter 54 sends compressed data to these home areas at a preferred compression ratio, e.g., more than approximately 2:1. The portion of each home area required to store data varies depending upon the amount of data being compressed, of course, but will never exceed the entire home area due to the compression.
With the system adapter [0029] 54 sending compressed data to the storage cache 60, an effective increase in bandwidth for data transfer results by a factor dependent upon the compression ratio. For example, with a compression ratio of about 3:1, data transfer can now effectively occur at three times the normal transfer rate, since three times as much data is able to be transferred, e.g., a rate of 100 MB/s (megabyte/second) now appears as 300 MB/s. Of course, a similar increase in bandwidth may be realized for data transfers from partition L3 to storage 62, since the data being transferred from partition L3 has already been compressed.
In terms of data flow, again an LRU algorithm suitably determines which data from partition L[0030] 3 becomes a victim line for storage in partition L4 with writing to storage 62, and similarly, which lines are victims from partition L4. The size of the blocks in partition L4 are smaller in comparison to the data block storage area/home areas of partition L3. Thus, a data sniffer 64 suitably determines whether a victim line from L3 will fit in partition L4. Compacting of data may occur in order to realize line transfer from L3 to L4. Data is suitably discarded from partition L4 via a bit bucket/discarder 65. When a hit occurs in partition L4, suitably the line is returned to partition L3 and to system adapter 54. The decompressor logic 58 suitably decompresses the data before being returned to system 50. If a miss occurs in both partitions L3 and L4, the data is returned from storage 62 to partition L3 and directly to system adapter 54 for decompression and return to system 50.
The caching arrangement aspects of the present invention are further capably utilized in systems that comprise multiple levels of caching. By way of example, FIG. 5([0031] a) illustrates a block diagram of typical multi-level caching, such as in a RAMAC storage system from IBM Corporation, Armonk, N.Y. An upper level cache 70 is shared among all of the lower level caches 72, each of which is shared among all of the drawer level caches 74, each of which is then shared among respective disk level caches 76. Conventionally, the LRU algorithm is employed at each of the levels. However, the addition of new data at the upper level cache 70 normally results in replacement of the data in each of the next lower cache levels, as well. Unfortunately, this results in duplication of cache lines, i.e., cache pollution, among the caches.
In accordance with a further aspect of the present invention, a multi-level caching arrangement utilizes dynamic partitioning, as described with reference to FIG. 5([0032] b). As shown in FIG. 5(b), each level of the multi-level caching arrangement employs dynamic partitioning of uncompressed and compressed data partitions. Thus, an upper, level one system cache 80 is partitioned into an uncompressed partition, IL3, and compressed partition, IL4. Similarly, a drawer level cache 82 comprises an uncompressed partition IIL3, and compressed partition IIL4, while a drive cache 84 associated with a DASD 86 includes a compressed partition IIIL4 and an uncompressed partition IIIL3. A compression sniffer 88 is further included and operates in a manner as previously described with reference to FIG. 1 to solve problems associated with compression ratio variability and prediction problems. Sizes of the partition L3 and partition L4 of each level are suitably adjusted dynamically to achieve desired performance characteristics, as described herein with reference to FIGS. 1-4.
The L[0033] 3 of cache level 80 suitably stores data that is changing, while the L3 of 82 and 84 suitably is used to store pre-fetched uncompressed data. The pre-fetch data comprises the excessive amount of data read in many environments. Alternatively, a specific command to pre-fetch large blocks of data units, or purge a large block of data in the cache, or freeze a block of data in cache, may be employed as is well understood by those skilled in the art.
In terms of data flow, the victim data unit (i.e., tracks, records, or lines) chosen at top-level IL[0034] 3 is compressed and then pushed to the top-level compressed partition IL4, represented by arrow 90. Alternatively, for compression ratio lower than the predetermined threshold or for a fast write operation, the IL3 victim data unit is suitably stored directly on DASD 86, represented by arrow 92. The victim data unit at each level of compressed partition L4 is pushed down to the next lower level compressed partition L4, i.e., the victim of IL4 is pushed down to IIL4 (arrow 94), and the victim of IIL4 is pushed down to IIIL4 (arrow 96). The victim of IIIL4 preferably is uncompressed(decompressed) and stored to DASD 86 (arrow 98). When a read data miss occurs in the IL3 partition, the missed data is preferably fed directly from either: compressed partition IL4 (arrow 99) after decompression; a lower level prefetch L3 (arrows 100 or 102); a lower level L4 (arrows 104 or 106) after decompression; or DASD 86 (arrow 102).
Thus, through the dynamic partitioning and data organization with multiple levels of caching as represented in FIG. 5([0035] b), duplication of data among the cache levels is readily avoided, while the data requesting path is made faster. Further, retaining victim lines in the described manner creates better performance than normal methods which throw victim lines away.
Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. For example, although the embodiment of FIG. 1 is described as partitioning a single physical cache, the partitions are suitably capable of being achieved with separate physical memory devices. Of course, a greater performance penalty results for misses in L[0036] 3 and hits in L4 when on separate memory devices. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims

What is claimed is:

1. A method for caching data in a data processing system, the method comprising:

partitioning a storage cache to include a compressed data partition and an uncompressed data partition; and

adjusting the compressed data partition and the uncompressed data partition for chosen performance characteristics, including overall cache size.

2. The method of

claim 1

wherein the performance characteristics further include cache partition ratios, a storage device size and performance objectives.

3. The method of

claim 1

wherein a trail compression unit determines space allocation for data in the compressed data partition to avoid problems associated with compression ratio variability and prediction.

4. The method of

claim 3

further comprising utilizing a predetermined compression ratio to form compressed data and storing the compressed data in the compressed data partition.

5. The method of

claim 4

wherein the compressed data partition stores a victim data unit from the uncompressed data partition, the victim data unit comprising a track, record, or line of data.

6. The method of

claim 5

wherein the victim data unit comprises least recently used data from the uncompressed data partition.

7. The method of

claim 4

wherein the compressed data partition stores a pre-fetch data unit from a storage device.

8. The method of

claim 4

further comprising storing the compressed data in-place in the storage cache.

9. The method of

claim 4

wherein the predetermined compression ratio comprises a ratio of more than approximately 2:1.

10. The method of

claim 5

further comprising storing the victim data unit directly to storage when the trail compression unit determines a compression ratio falls below a given threshold.

11. The method of

claim 7

wherein the storage device comprises a direct access storage device (DASD).

12. The method of

claim 4

further comprising tracking a status of data lines in the storage cache with a directory to identify whether the data lines are compressed or uncompressed.

13. A data caching system in a data processing system, the data processing system including a host system in communication with a storage system, the data caching system comprising:

at least one storage device; and

at least one cache coupled to the at least one storage device for caching data from the at least one storage device, the at least one cache partitioned to include a compressed partition and an uncompressed partition, wherein the uncompressed partition stores at least a victim data unit from the uncompressed partition.

14. The system of

claim 13

wherein the storage system further comprises a compression sniffer coupled to the at least one partially compressed cache to determine space allocation in the compressed partition.

15. The system of

claim 13

wherein the at least one partially compressed cache comprises an upper level cache of uncompressed data and at least one lower level cache of compressed data.

16. The system of

claim 13

wherein the compressed partition further stores prefetch storage data.

17. The system of

claim 13

wherein the victim data unit comprises least recently used data from the uncompressed partition.

18. The system of

claim 13

wherein the storage system further comprises a compressor and a decompressor coupled to the at least one partially compressed cache.

19. The system of

claim 17

wherein the compressor compresses the victim data unit at a ratio of more than approximately 2:1.

20. A method for effectively increasing data transfer bandwidth between a host system and a storage system, the method comprising:

utilizing a system adapter in the storage system for storage data transfer, the system adapter including compression logic and decompression logic;

coupling at least one partially compressed cache to the system adapter, the at least one partially compressed cache comprising an uncompressed partition and a compressed partition; and

transferring data through the compression logic to the uncompressed partition to effectively increase data transfer from the system adapter to the partially compressed cache by a factor corresponding to a compression ratio of the compression logic.

21. The method of

claim 20

wherein the compression ratio comprises more a compression ratio of more than approximately 2:1.

22. The method of

claim 20

further comprising storing victim lines from the uncompressed partition in the compressed partition.

23. The method of

claim 22

further comprising writing the victim lines to a storage device in the storage system.

24. A method for caching data in a multi-level caching arrangement of a data processing system, the method comprising:

partitioning each cache level to include a compressed data partition and an uncompressed data partition;

adjusting the compressed data partition and the uncompressed data partition of each cache level for chosen performance characteristics; and

utilizing the compressed and uncompressed data partitions of each cache level to cache data from a storage device, wherein cache pollution is substantially avoided and a data requesting path becomes faster.

25. The method of

claim 24

further comprising storing pre-fetched uncompressed storage data in the uncompressed data partition of each cache level.

26. The method of

claim 25

further comprising compressing a victim data unit of an uncompressed data partition of a top level cache and storing the victim data unit in a compressed data partition of the top level cache.

27. The method of

claim 26

further comprising utilizing a predetermined compression ratio to form compressed data for the compressed data partition.

28. The method of

claim 26

further comprising utilizing a trail compression unit for estimating space allocation for data in the compressed data partition to avoid problems associated with compression ratio variability and prediction.

29. The method of

claim 26

further comprising storing a victim data unit of the compressed data partition of one cache level in a compressed data partition of a next lower cache level.

30. The method of

claim 29

further comprising decompressing a victim data unit of a compressed data partition of a lowest level cache for storage back in the storage device.

31. A data processing system comprising:

a host system, the host system performing accesses on storage data; and

a storage system, the storage system coupled to the host system and storing the storage data, the storage system comprising multiple cache levels, each cache level comprising a compressed data partition and an uncompressed data partition.

32. The system of

claim 31

wherein a compressed data partition of a top level cache stores a victim data unit of a top level uncompressed data partition.

33. The system of

claim 32

wherein a compressed data partition of each lower level cache stores a victim data unit of a compressed data partition of a next higher level cache.

34. The system of

claim 33

wherein the storage subsystem further comprises a storage device coupled to the multiple cache levels, the storage device storing a victim data unit from a compressed data partition of a lowest cache level.