A storage server is a computer system that is used to store and retrieve data on behalf of one or more clients on a network. The data within the storage server is typically stored on writable persistent storage media, such as non-volatile memories and disks. The various types of non-volatile storage media used by a storage server can have different latencies. In many cases, data is stored on hard disk drives (HDDs), which have a relatively high latency. In HDDs, disk access time includes the disk spin-up time, the seek time, rotational delay, and data transfer time. HDDs generally provide good performance when reading large blocks of data, which is stored sequentially on the physical media. However, HDDs do not perform as well for random accesses because the mechanical components of the device must frequently move to different physical locations on the media.
In other cases, data are stored on solid-state drives (SSDs). SSDs generally have lower latencies than HDDs. SSDs use solid-state memory, such as non-volatile flash memory, to store data. With no moving parts (mechanical delays inherent in the operation of the HDD), SSDs typically provide better performance for random and frequent memory accesses because of the relatively low latency. However, SSDs are generally more expensive than HDDs and sometimes have a shorter operational lifetime due to wear and other degradation. These additional up-front and replacement costs can become significant for data centers, which have many storage servers using many thousands of storage devices.
Hybrid storage aggregates combine the benefits of HDDs and SSDs. SSDs make up part of the hybrid storage aggregate and provide high performance, while relatively inexpensive HDDs make up the remainder of the storage array. Lower latency storage is often used as a cache for the higher latency storage. Copies of the most frequently accessed data are stored in the cache. When a data access is performed, the faster cache may first be checked to determine if the required data are located therein, and, if so, the data may be accessed from the cache. In this manner, the cache reduces overall data access times by reducing the number of times the higher latency devices must be accessed. In some cases, cache space is used for data that is being frequently written (i.e., a write cache). In addition, cache space is used for data that is being frequently read (i.e., read cache).
Some conventionally caching regimes are closely tied to inode and buffer context, which may be problematic. The inode is the starting point for finding the locations of all of the associated data blocks that make up the file. Determining the actual physical location of a block may require working through the inode and one or more levels of indirect blocks. FIG. 1 illustrates two buffer trees, one associated with inode 122A and another associated with inode 122B. Inode 122A points to or references level 1 indirect blocks 124A and 124B. Each of these indirect blocks points to the actual physical storage locations of the data blocks which store the data. HDD array 160 is bypassed when reading this block. The performance of the storage system is improved because the data can be read from data block 183 more quickly than it could be from data block 163. Typically many more data blocks will be included in a read cache. Only one block is illustrated in FIG. 1 for purposes of illustration. None of the data blocks associated with inode 122B are cached in this example.
In some cases, multiple levels of indirect blocks are used. An indirect block may point to another indirect block where the latter indirect block points to the physical storage location of the data. Additional layers of indirect blocks are possible. In this case, there has to be an inode attached to the data before caching, which does not allow for caching random data. The fill patterns of the data blocks illustrated in FIG. 1 are indicative of the content of the data blocks. For example, data block 163 and data block 183 contain identical data. At a previous point in time, data block 163 was determined to be frequently accessed and a copy of data block 163 was created in SSD array 170 (i.e., data block 183). Metadata associated with data block 163 in indirect block 124B was updated such that requests to read data block 163 are pointed to data block 183. This is referred to as “dirtying” the inode. A block is considered “clean” when the newest value of the block has been successfully stored and processed within a storage system and “dirty” when the value of the block in the cache is newer than the copy of the block in the storage system. The event during which dirty data blocks stored in the main buffer cache are written to the storage system is called a consistency point.
Unnecessary dirtying of the inode is done for caching which puts pressure on the consistency point process. Dirtying inodes include tagging inodes to direct to new blocks containing modified data. During the consistency point process, the storage server commits the data blocks to a nonvolatile mass storage facility by compressing the data blocks, encrypting selected data blocks, and storing the compressed and (possibly) encrypted data blocks in the SSD based on the dirtied inode (e.g. copying data block 163 into data block 183). It is not unlikely for the consistency point process to encounter issues because too many inodes are dirtied. Complications arise as a result of two or more different types of dirty types of inodes. In situations where the data is stored in read-only volumes, the inodes are unable to be dirtied. As a result, the hybrid aggregates is not configured to utilize the lower latency storage of SSD to cache read-only data in snapshots, or snap-mirror destinations. In addition, there is a logical context attached with the inode requiring strict adherence to the specific operating system for which it resides. As a result, caching may not be achieved if the operating system's protocol is not configured to dirty an inode. Disclosed, for example, is block based caching as opposed to writing the allocation of SSD cached blocks from an inode or volume file-system context.
The present disclosure is susceptible to various modifications and alternative forms, and some representative embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the inventive aspects are not limited to the particular forms illustrated in the drawings. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims.