Storing compressed and uncompressed data in blocks having different allocation unit sizes

Improved techniques for storing data involve storing compressed data in blocks of a first AU size and storing uncompressed data in blocks of a second AU size larger than the first AU size. For example, when a storage processor compresses a chunk of data, the storage processor checks whether the compressed chunk fits in the smaller AU size. If the compressed chunk fits, then the storage processor stores a compressed chunk in a block having the smaller AU size. Otherwise, the storage processor stores the uncompressed chunk in a block having the larger AU size. Advantageously, the improved techniques promote better disk and cache utilization, which improves performance without disrupting block mapping.

BACKGROUND

Data storage systems are arrangements of hardware and software that include storage processors coupled to arrays of non-volatile storage devices. In typical operation, storage processors service storage requests that arrive from client machines. The storage requests specify files or other data elements to be written, read, created, or deleted, for example. The storage processors run software that manages incoming storage requests and performs various data processing tasks to organize and secure the data stored on the non-volatile storage devices.

Some data storage systems employ compression technology to better utilize storage resources on the non-volatile storage devices. For example, a data storage system may operate in the background to compress data stored in the non-volatile storage devices. Compression enables the data storage system to store more data in the same amount of non-volatile storage.

SUMMARY

Conventional data storage systems generally provide blocks of storage in a single allocation unit (AU) size, such as 8 KB. Unfortunately, storing compressed data in uniformly-sized blocks offers little benefit over storing uncompressed data as data storage systems generally read and write data on a block-by-block basis. It may be possible to consolidate multiple blocks' worth of compressed data into fewer numbers of blocks, but this is disruptive to block mapping, such a mapping provided in inode pointers and indirect block trees.

In contrast with the above-described conventional approach to compression, which either offers little benefit over storing uncompressed data or is disruptive to mapping, improved techniques for storing data involve storing compressed data in blocks of a first AU size and storing uncompressed data in blocks of a second AU size larger than the first AU size. For example, when a storage processor compresses a chunk of data, the storage processor checks whether the compressed chunk fits in the smaller AU size. If the compressed chunk fits, then the storage processor stores a compressed chunk in a block having the smaller AU size. Otherwise, the storage processor stores the uncompressed chunk in a block having the larger AU size. Advantageously, the improved techniques promote better disk and cache utilization, which improves performance without disrupting block mapping.

One embodiment is directed to a method of processing write requests in a data storage system. The method includes receiving write requests from a set of hosts, the write requests specifying data to be written to non-volatile storage. The method also includes storing a first portion of the data in compressed form in blocks of non-volatile storage having a first allocation unit size. The method further includes storing a second portion of the data in uncompressed form in blocks of non-volatile storage having a second allocation unit size, the second allocation unit size being larger than the first allocation unit size.

Additionally, some embodiments are directed to a system constructed and arranged to process write requests in a data storage system. The system includes memory and a controller including controlling circuitry constructed and arranged to carry out a method of processing write requests in a data storage system.

Further, some embodiments are directed to a computer program product having a non-transitory computer readable storage medium that stores instructions which, when executed by a computer, cause the computer to carry out the method of processing write requests in a data storage system.

DETAILED DESCRIPTION

Improved techniques for storing data in a data storage system involve storing compressed data in blocks of a first AU size and uncompressed data in blocks of a second AU size larger than the first AU size. Advantageously, the improved techniques promote better disk and cache utilization, which improves performance without disrupting block mapping.

FIG. 1shows an example electronic environment100in which embodiments of the improved techniques hereof can be practiced. Here, multiple host computing devices (“hosts”)110(1) through110(N) access a data storage apparatus116over a network114. The data storage apparatus116includes a storage processor, or “SP,”120and non-volatile storage180. The storage180is provided, for example, in the form of hard disk drives and/or electronic flash drives. The data storage apparatus116may include multiple SPs like the SP120. For instance, the data storage system116may include a second SP120a. In an example, multiple SPs may be provided as circuit board assemblies, or “blades,” which plug into a chassis that encloses and cools the SPs. The chassis has a backplane for interconnecting the SPs, and additional connections may be made among SPs using cables. It is understood, however, that no particular hardware configuration is required, as any number of SPs (including a single one) can be provided and the SP120can be any type of computing device capable of processing host IOs. Additional information about data storage systems in which the improved technique hereof can be practiced is found in U.S. patent application Ser. No. 13/828,322, filed Mar. 14, 2013, the contents and teachings of which are incorporated by reference herein in their entirety.

The network114can be any type of network or combination of networks, such as a storage area network (SAN), local area network (LAN), wide area network (WAN), the Internet, and/or some other type of network, for example. In an example, the hosts110(1-N) can connect to the SP120using various technologies, such as Fibre Channel (e.g., through a SAN), iSCSI, NFS, SMB 3.0, and CIFS. Any number of hosts110(1-N) may be provided, using any of the above protocols, some subset thereof, or other protocols besides those shown. The SP120is configured to receive IO requests112(1-N) and to respond to such IO requests112(1-N) by reading and/or writing the non-volatile storage180.

The SP120is seen to include one or more communication interfaces122, a set of processing units124, and memory130. The communication interfaces122include, for example, adapters, such as SCSI target adapters and network interface adapters, for converting electronic and/or optical signals received from the network114to electronic form for use by the SP120. The set of processing units124include one or more processing chips and/or assemblies. In a particular example, the set of processing units124includes numerous multi-core CPUs. The memory130includes both volatile memory (e.g., RAM), and non-volatile memory, such as one or more ROMs, disk drives, solid state drives, and the like. The set of processing units124and the memory130together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. Also, the memory130includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processing units124, the set of processing units124are caused to carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory130typically includes many other software constructs, which are not shown, such as an operating system, various applications, processes, and daemons, for example.

The memory130is seen to include (i.e., realize by operation of programming code) an IO stack140. The IO stack140provides an execution path for host IOs (e.g., IO requests112(1-N)). The IO stack140, inter alia, a volatile memory cache150, compression logic154, a file system160, and a second cache170. The underlying data and metadata that support the file system160typically reside in the storage180.

Portions of the memory130that support the volatile memory cache150may be realized in volatile memory, e.g., DRAM, within SP120. In an example, the SP120ahas a similar volatile memory cache150that is configured to mirror data stored in the DRAM of the SP120.

The data storage apparatus116is also seen to include battery backup190and190aconnected to respective SPs120and120a, for powering their respective DRAMs in case of an unexpected loss of power. Hence, the battery backups190and190amake it possible for data in the volatile memory cache150to be deemed persisted even though it may only be stored in volatile memory. Such persistence allows the SP120to send acknowledgments126(1. . . N) to respective hosts110(1. . . N) as soon as data from IO requests112(1. . . N) are written to the volatile memory cache150and mirrored to the SP120a. Such rapid acknowledgments to the IO requests112(1. . . N) helps in maintaining a high quality of service for the hosts110(1. . . N).

Compression logic154includes instructions to cause one or more of the processing units124to compress data residing in the volatile memory cache150.

In an example, the file system160is a container file system storing a container file representing a data object, such as a host file system (HFS), a virtual volume (vVol), or a LUN. The SP120may host any number of such container file systems. Each such container file system includes a respective inode table. The inode table includes inodes providing file-specific information about each file in the respective container file system. The information stored in each inode includes location information (e.g., block locations) where data of the respective file are stored. It should be understood that any container file system might contain multiple files, with each having its own entry in the respective inode table. In some arrangements, each container file system stores not only a file representing a data object, but also snaps of that file and therefore snaps of the data object the file stores.

It should further be understood that a container file system may be allocated storage from a storage pool in the form of “slices.” A “slice” is an increment of storage space, such as 256 MB or 1 GB in size, which is derived from the non-volatile storage180. The pool may allocate slices to a container file system, e.g., file system160, for use in storing its files. The pool may also deallocate slices from the container file system if the storage provided by the slices is no longer required. In an example, the storage pool creates slices by accessing RAID groups, dividing the RAID groups into FLUs (Flare LUNS), and further dividing the FLUs into slices.

The file system160supports storage of compressed data162and uncompressed data164within the non-volatile storage180in blocks having different allocation unit (AU) sizes. As illustrated inFIG. 1, the file system160supports blocks182of smaller AU size, e.g., 8 KB, for storing the compressed data162, and blocks184of larger AU size, e.g., 32 KB, for string the uncompressed data164.

In some arrangements, the data storage system116arranges blocks in different slices according to AU size. By keeping blocks182of smaller AU size and blocks184of larger AU size in separate slices, problems stemming from defragmentation may be avoided.

The secondary cache170provides data caching for the storage180. It may be implemented within volatile memory within the memory130.

During operation, SP120receives IO requests112from hosts110over the network114. When the IO requests112are write requests, SP120stores data specified by the write requests in the volatile memory cache150.

In some arrangements, SP120mirrors the data from the write requests into a volatile memory cache150within SP120a. When SPs120and120ahave battery backup (190and190a) for their volatile memory cache150, the SP120may send acknowledgments126(1),126(2), . . . ,126(N) of the write requests to respective hosts because the data may be deemed persisted once it has been cached and mirrored.

The SP120executes compression logic154to compress data specified in write requests. In some arrangements, the SP120compresses the data in an inline manner prior to the data being written to the non-volatile storage180. The data may be stored in compressed form and/or uncompressed form, depending on whether the data in compressed form fits in blocks182of the smaller AU size. The SP120may also compress data in a background manner after storing data in non-volatile storage180, for example, in situations in which it is not feasible to perform compression in-line.

FIG. 2shows an example method200of deciding which of data specified in write requests the SP120stores as compressed data, and which of the data the SP120stores as uncompressed data.

At212, the SP120caches data specified by the write requests in the volatile memory cache150, as described above in connection withFIG. 1.

At214, the SP120aggregates the data into chunks in the volatile memory cache150. In an example, the chunks have a data size equal to the AU size of the larger blocks184.

SP120then performs a decision operation216to decide whether to store the chunks in compressed or uncompressed form. Decision operation216includes sub-processes “A”, “B”, and “C”. “A” and “B” are optional processes but each may terminate the decision process prior to initiating process “C”. Sub-processes “A” and “B” will be discussed in connection withFIGS. 4A, 4B, and 4C.

SP120carries out process “C” to determine whether a compression operation sufficiently compresses a chunk so that the resulting compressed chunk fits in a smaller block182. At218, SP120performs a trial compression operation on a chunk of data stored in the volatile memory cache150. The particular approach used to achieve compression may be any type of compression algorithm and will not be described further. At220, the SP120tests whether the resulting compressed chunk of data fits in a block of storage182having the smaller AU size.

If the compressed chunk does fit in the block182having the smaller AU size, then, at222, SP120stores the compressed chunk within the block182having the smaller AU size. If not, then, at224, SP120stores the uncompressed chunk within the block184having the larger AU size.

FIG. 3illustrates a further example of the above-described process “C”. Process “C” begins with chunks310(a),310(b),310(c),310(d), . . . ,310(n) (chunks310), which reside within the volatile memory cache150. Each of the chunks310has a data size equal to the larger AU size, e.g., 32 KB.

In this example, the compression logic154performs a compression operation on each of the chunks310. It should be understood that, while the sizes of each chunk310may be the same, the size of the resulting compressed chunks are likely to be different, as the size of a compressed chunk depends on the content of its data, as well as other factors. Compression of, for example, chunks310(a) and310(d) results in respective compressed chunks320(a) and320(d).

Compressed chunks320(a) and320(d) each undergo a testing operation (e.g., at220ofFIG. 2) in which their sizes are compared with the smaller AU size. In this specific instance, compressed chunk320(a) fits within the smaller AU size, while compressed chunk320(d) does not fit within the smaller AU size. This is the case even though the data size of compressed chunk320(d) may be substantially smaller than that of its respective uncompressed chunk310(d). Thus, in this specific example, SP120stores the compressed chunk320(a) in a smaller AU block182, while SP120stores the uncompressed chunk310(d) in a larger AU block184.

It should be understood that the decision operation216(seeFIG. 2) might include other processes, which may involve evaluating conditions within the data storage system116to decide whether a compression operation should even be attempted.

FIG. 4Ashows the volatile memory cache150, which is seen to have a high water mark420and low water mark430.

The high water mark420is defined as a high level of utilization of the volatile memory cache150, e.g., 80%. Above the high water mark420, the SP120will cease performing trial compression operations, as the volatile memory cache150is at risk of being overrun and continuing trial compression may slow down acknowledgments to the hosts110. The low water mark430is defined as a level of utilization sufficiently below the high water mark430at which the SP120will resume trial compression operations after the level of utilization has already exceeded the high water mark420. Typically, the low water mark430is 20% below the high water mark420, but other values for the low water mark430may be used. The difference between the high water mark and the low water mark prevents cluttering around a single threshold.

FIG. 4Billustrates an example method400of carrying out process “A” to determine, from the utilization of the volatile memory cache150, whether to carry out a trial compression operation on a current chunk of data.

At440, the SP120measures the utilization of the volatile memory cache150, e.g., using any known method. At442, the SP120compares the utilization of the volatile memory cache150to the high water mark420. If the utilization exceeds the high water mark, or has exceeded the high water mark420and has not subsequently crossed the low water mark430, then the SP120stops performing trial compression operations until the utilization falls below the low water mark430. Until then, the SP120stores the uncompressed, current chunk in a block184having the larger AU size in the non-volatile storage180(at224as described above), and the method400is complete. Otherwise, at446, the SP120may begin a compression operation on the current chunk.

FIG. 4Cillustrates an example method450of carrying out process “B” to determine, based on a recent history of compression failures, whether to carry out a trial compression operation on the current chunk.

At460, the SP120checks a recent history of compression failures to determine a pattern of compression failures out of a total number of compression attempts. The recent history may be taken over a time scale of milliseconds or seconds, although longer and shorter time scales might be used. In some arrangements, checking the recent history may involve computing a simple percentage of compression failures, computing a weighted distribution of the compression failures over time, or other techniques. The SP120may store the recent history in the memory130.

It should be understood that a “compression failure” as used above does not imply a failure of the compression operation, per se, but rather a failure to produce a compressed chunk that fits in a block182having the smaller AU size.

At470, the SP120determines whether a pattern (e.g., calculated percentage or distribution) of compression failures in the recent history exceeds a predetermined threshold. If so, then the SP120, at224as described above, stores the current, uncompressed chunk in a block184of larger AU size in the non-volatile storage180. The method450for the current chunk is then complete. Otherwise, the SP120begins a compression operation in process “C”, as described above, at446.

If there is no such pattern of compression failures, then at490, the SP120determines whether a predetermined event has occurred that would trigger a resumption of compression operations. In some arrangements, the passage of a specified amount of time since trial compression operations were stopped serves as such an event. For example, trial compressions are stopped if there has been a recent history of compression failures, but they are resumed after a specified amount of time. In other arrangements, the receipt of write requests from a new application serves as such an event. If the SP120detects such a predetermined event, then the SP120proceeds to process “C” at495. Otherwise, the SP120, at480, stores the current, uncompressed chunk in a block184of larger AU size in the non-volatile storage180.

FIG. 5Aillustrates an example leaf indirect block510of the file system160. It should be understood that when the file system160is a container file system with a single file having an inode, the inode contains pointers to indirect blocks, which in turn point to other indirect blocks and/or to data blocks. The leaf indirect block510of such a container file system is a leaf node of an indirect block tree referenced in the inode and contains pointers520to data blocks stored within the non-volatile storage180. It should be understood that some of these pointers520point to blocks182having the smaller AU size and containing data in compressed form, whereas others of these pointers520point to blocks184having the larger AU size and containing data in uncompressed form.

In some examples, the leaf indirect block510also contains corresponding compression bits530and compression failure bits540, one of each bit for each pointer520. In an example, each compression bit530takes the value “0” when its corresponding pointer points to a block184having the larger AU size containing data in uncompressed form and the value “1” when its corresponding pointer points to a block182having the smaller AU size containing data in compressed form. The SP120uses a compression bit530to quickly determine whether the data being pointed to is compressed or not. The value of the compression failure bit540is meaningful only when its corresponding pointer520has a compression bit value of “0”. In an example, each compression failure bit540takes the value “1” when a compression operation on the pointed-to data was attempted and failed. The bit540may be set to “0” when there was no such compression operation attempted, e.g., when the utilization of the volatile memory cache150was above the high water mark. The usefulness of a compression failure bit540is that it allows the SP120to determine whether it might still be possible to compress the pointed-to, uncompressed data. When no attempt at compression of that data has been made, then the SP120may attempt a background compression on the data.

FIG. 5Billustrates a method500of reading a block of data within the electronic environment100. As part of the method500, the SP120refers to the leaf indirect block610when requested to access the data in the non-volatile storage180. At550, the SP120receives a read request to read a data object stored in the file system160. At552, the SP120locates the pointer620to a block within the leaf indirect block510of a container file system containing a file realizing the data object. At554, the SP120determines whether the pointer620points to compressed data (i.e., stored in smaller block182) or uncompressed data (i.e., stored in larger block184). In some arrangements, the SP120makes such a determination from the compression bit630for that pointer. If the pointer620points to compressed data, then the SP120, at556, reads the data and, at558, decompresses the data. If, however, the pointer620points to uncompressed data, then, at560, the SP120simply reads the data.

FIG. 6illustrates a method600of performing deduplication on blocks within the file system160. At610, the SP120receives a command to perform a deduplication operation on blocks of the file system160. At620, the SP120reclaims duplicate blocks182with the smaller AU size. In step630, the SP120reclaims duplicate blocks184with the larger AU size. It should be understood that the duplicate blocks are replaced with pointers to remaining blocks having the same content as the reclaimed blocks, regardless of the AU size of those blocks and regardless of whether the data in those blocks is compressed or uncompressed.

FIG. 7Ashows a file inode720and a snap file inode722resulting from a snapshot operation within the file system160. The snap file inode722contains pointers730to blocks182of smaller AU size and blocks184of larger AU size in non-volatile storage180, compression bits740, and compression failure bits750.

FIG. 7Billustrates a method700of performing a snapshot operation on files within the file system160. As part of the method700, the SP120, at760, performs a snapshot operation on the file having the file inode720. In an example, the file is a container file that realizes a LUN, host file system, or vVol, for example. At770, the SP120generates a new snap file having the snap file inode722. Thus, the snapshot operation can be performed on the file without regard for the AU size of the pointed-to blocks or whether they store compressed or uncompressed data.

FIG. 8illustrates a method800of processing write requests in a data storage system, including steps802,804and806.

At802, the data storage system receives write requests from a set of hosts over a network, the write requests specifying data to be written to non-volatile storage. For example, the SP120of the data storage system116receives write requests112over the network114specifying data to be written to non-volatile storage180.

At804, the data storage system stores a first portion of the data in compressed form in blocks of non-volatile storage having a first allocation unit size. For example, the SP120may compress chunks of data and store those compressed chunks that fit in the blocks182having smaller AU size.

At806, the data storage system stores a second portion of the data in uncompressed form in blocks of non-volatile storage having a second allocation unit size, the second allocation unit size being larger than the first allocation unit size. For example, the SP120stores the uncompressed blocks in blocks184having the larger AU size when compression of those blocks yields compressed blocks that do not fit in the smaller AU size.

Improved techniques have been disclosed that involve a storage processor of a data storage system storing compressed data in blocks of a first AU size and uncompressed data in blocks of a second AU size larger than the first AU size. Advantageously, this allows for more effective compression while preserving block mapping in a file system.

Having described certain embodiments, numerous alternate embodiments or variations can be made. For example, while the above examples provide for two AU sizes, in some arrangements the file system may support more than two AU sizes for blocks of storage in the non-volatile storage system180. In particular, there may be a third, intermediate AU size, e.g., 16 KB, in between a larger AU size, e.g., 32 KB, and a smaller AU size, e.g., 8 KB. In this case, the compression logic154would direct the SP to store those chunks that compress to a size between 8 KB and 16 KB in compressed form in a block having the AU size of 16 KB, rather than in uncompressed form in a black having the AU size of 32 KB.

Further, while the above examples are directed to inline compression, in which the compression operations are performed prior to storage in the non-volatile storage medium180, in some arrangements the SP120may perform background compression operations after storage in the non-volatile storage medium180.

Furthermore, it should be understood that some embodiments are directed to data storage apparatus116containing storage processor120, which is constructed and arranged to process write requests in a data storage system. Some embodiments are directed to a process of processing write requests in a data storage system. Also, some embodiments are directed to a computer program product that enables computer logic to cause a computer to process write requests in a data storage system in a computing environment.

In some arrangements, storage processor120is implemented by a set of cores or other types of control/processing circuitry running software. In such arrangements, the software instructions can be delivered, within storage processor120, either in the form of a computer program product910, or simply instructions on disk or pre-loaded in memory130of data storage system116, each computer program product having a computer readable storage medium which stores the instructions in a non-volatile manner. Alternative examples of suitable computer readable storage media include tangible articles of manufacture and apparatus such as CD-ROM, flash memory, disk memory, tape memory, and the like.