Azor: Using Two-Level Block Selection to Improve SSD-Based I/O Caches

Abstract

Abstract-Flash-based solid state drives (SSDs) exhibit potential for solving I/O bottlenecks by offering superior performance over hard disks for several workloads. In this work we design Azor, an SSD-based I/O cache that operates at the block-level and is transparent to existing applications, such as databases. Our design provides various choices for associativity, write policies and cache line size, while maintaining a high degree of I/O concurrency. Our main contribution is that we explore differentiation of HDD blocks according to their expected importance on system performance. We design and analyze a two-level block selection scheme that dynamically differentiates HDD blocks, and selectively places them in the limited space of the SSD cache.We implement Azor in the Linux kernel and evaluate its effectiveness experimentally using a server-type platform and large problem sizes with three I/O intensive workloads: TPC-H, SPECsfs2008, and Hammerora. Our results show that as the cache size increases, Azor enhances I/O performance by up to 14.02×, 1.63×, and 1.55× for each workload respectively. Additionally, our two-level block selection scheme further enhances I/O performance compared to a typical SSD cache by up to 95%, 16%, and 34% for each workload, respectively.

Vanguard

“…A further degree of control is the capability to provide per-workload instances of the filesystem journal, thus providing each workload with a separate access path to the underlying storage devices. In this paper, we evaluate the effectiveness of this approach for a variety of workloads running on a virtualization host that has two types of devices, solid-state devices (SSDs) and hard disks, arranged so that the SSDs serve as a transparent cache (pFlash) for the underlying hard disks( [12]). With Vanguard we achieve three prerequisites for performance isolation: (1) enforce per-workload limits on the amount of I/O memory and SSD cache, (2) reduce contention across workloads due to synchronization and global policies in the hypervisor, and (3) allow I/O memory and threads to be placed with improved thread/data affinity, on servers which exhibit more pronounced NUMA and contention effects.…”

“…Completing our I/O-Stack we include pFlash, a blocklevel write-back SSD cache, derived from our own previous work [12]. pFlash is a transparent cache, as it exports a block device with size equal to the size of the device being cached.…”

Analysis of Prediction and Replacement Algorithms Applied to Real Workload for Storage Devices

“…In [12] is examined how SSDs can be used as a large cache on top of RAID to conserve energy. More recently, Klonatos et al [13] designed the Azor system that uses SSDs as caches in the I/O path to transparently and dynamically place data blocks in the SSDs. In all cases SSDs demonstrate potential for improved performance.…”

“…Recently, SSD devices became a faster option to disks. As SSD is much more expensive than common disks but cheaper than RAM, it is sometimes used as a cache layer [1] for storage.…”

LBICA: A Load Balancer for I/O Cache Architectures

“…1). Inclusion of SSDs in the I/O caching layer of systems improves the response time of the requests supplied by the cache, and hence, a wide range of enterprise and academic I/O cache architectures are proposed with the purpose of maximizing the hit ratio of the caching layer [10], [11], [12], [2], [13], [3], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28]. In these I/O caching schemes, mainly based on datapath or push mode cache architectures, the entire accesses are directed to the caching layer [29] and as such, the highest number of requests is responded via the caching layer to achieve the highest performance in terms of hit ratio.…”