Today's data storage systems are increasingly adopting low-cost disk drives that have higher capacity but lower reliability, leading to more frequent rebuilds and to a higher risk of unrecoverable media errors. We propose an efficient intradisk redundancy scheme to enhance the reliability of RAID systems. This scheme introduces an additional level of redundancy inside each disk, on top of the RAID redundancy across multiple disks. The RAID parity provides protection against disk failures, whereas the proposed scheme aims to protect against media-related unrecoverable errors. In particular, we consider an intradisk redundancy architecture that is based on an interleaved parity-check coding scheme, which incurs only negligible I/O performance degradation. A comparison between this coding scheme and schemes based on traditional Reed--Solomon codes and single-parity-check codes is conducted by analytical means. A new model is developed to capture the effect of correlated unrecoverable sector errors. The probability of an unrecoverable failure associated with these schemes is derived for the new correlated model, as well as for the simpler independent error model. We also derive closed-form expressions for the mean time to data loss of RAID-5 and RAID-6 systems in the presence of unrecoverable errors and disk failures. We then combine these results to characterize the reliability of RAID systems that incorporate the intradisk redundancy scheme. Our results show that in the practical case of correlated errors, the interleaved parity-check scheme provides the same reliability as the optimum, albeit more complex, Reed--Solomon coding scheme. Finally, the I/O and throughput performances are evaluated by means of analysis and event-driven simulation.

Distributed sparing is a method to improve the performance of RAID5 disk arrays with respect to a dedicated sparing system with N+2 disks (including the spare disk), since it utilizes the bandwidth of all N+2 disks. We analyze the performance of RAID5 with distributed sparing in normal mode, degraded mode, and rebuild mode in an OLTP environment, which implies small reads and writes. The analysis in normal mode uses an M/G/1 queuing model, which takes into account the components of disk service time. In degraded mode, a low-cost approximate method is developed to estimate the mean response time of fork-join requests resulting from accesses to recreate lost data on the failed disk. Rebuild mode performance is analyzed by considering an M/G/1 vacationing server model with multiple vacations of different types to take into account differences in processing requirements for reading the first and subsequent tracks. An iterative solution method is used to estimate the mean response time of disk requests, as well as the time to read each disk, which is shown to be quite accurate through validation against simulation results. We next compare RAID5 performance in a system (1) without a cache; (2) with a cache; and (3) with a nonvolatile storage (NVS) cache. The last configuration, in addition to improved read response time due to cache hits, provides a fast-write capability, such that dirty blocks can be destaged asynchronously and at a lower priority than read requests, resulting in an improvement in read response time. The small write penalty is also reduced due to the possibility of repeated writes to dirty blocks in the cache and by taking advantage of disk geometry to efficiently destage multiple blocks at a time.

Disk Arrays or RAIDs are a widely accepted I/O system architecture, useful for a wide range of applications. Before a RAID can be used, one needs to configure the RAID to select parameters such as the RAID level to use, the stripe unit to use, how large a cache to use, and so on. Selecting these configuration parameters can be quite complex, yet no aids are available today to help the user configure his RAID. The optimal selection of the parameters strongly depends on the specific workload characteristics of the application. In this paper we describe a configuration tool called Raidtool which is intended to support the systems designer in the selection of the configuration parameters. Our approach consists of three basic steps. The first step is to collect a trace of I/Os while running one or more typical applications. In the second step, this trace data is analyzed to determine the workload characteristics of the applications. In the third and final step, we use a simulator to evaluate the different RAID controller configurations.

This paper considers the performance of cached RAID5 using simulations that are driven by database I/O traces collected at customer sites. This is in contrast to previous performance studies using analytical modelling or random-number simulations. We studied issues of cache size, disk buffering, cache replacement policies, cache allocation policies, destage policies and striping. Our results indicate that: read caching has considerable value; a small amount of cache should be used for writes fast write logic can reduce disk utilization for writes by an order of magnitude; priority queueing should be supported at the disks; disk buffering prefetch should be used; for large caches, it pays to cache sequentially accessed blocks; RAID5 with cylinder striping is superior to parity striping.>

In this paper, we compare the performance of the well-known RAID-5 arrays to that of log-structured arrays (LSA), on transaction-processing workloads. LSA borrows heavily from the log-structured file system (LFS) approach, but is executed in an outboard disk controller. The LSA technique we examine combines LFS, RAID, compression and non-volatile cache. We look at sensitivity of LSA performance to amount of free space on the physical disks and to the compression ratio achieved. We also evaluate a RAID-5 design that supports compression in cache.

We present a novel method, that we call EVENODD, for tolerating up to two disk failures in RAID architectures. EVENODD employs the addition of only two redundant disks and consists of simple exclusive-OR computations. This redundant storage is optimal, in the sense that two failed disks cannot be retrieved with less than two redundant disks. A major advantage of EVENODD is that it only requires parity hardware, which is typically present in standard RAID-5 controllers. Hence, EVENODD can be implemented on standard RAID-5 controllers without any hardware changes. The most commonly used scheme that employes optimal redundant storage (i.e., two extra disks) is based on Reed-Solomon (RS) error-correcting codes. This scheme requires computation over finite fields and results in a more complex implementation. For example, we show that the complexity of implementing EVENODD in a disk array with 15 disks is about 50% of the one required when using the RS scheme. The new scheme is not limited to RAID architectures: it can be used in any system requiring large symbols and relatively short codes, for instance, in multitrack magnetic recording. To this end, we also present a decoding algorithm for one column (track) in error.>

We analyze the performance of RAIDS disk arrays in normal, degraded, and rebuild modes. The analysis, which is shown to be highly accurate through validation against simulation results, achieves its accuracy by (1) modeling detailed disk characteristics; (2) developing a simple approximation to compute the mean response time for fork-join requests arising in degraded mode operation; and (3) using a vacationing server model with multiple vacation types for rebuild mode analysis. According to this model vacations (rebuild reads) are started when the server (disk) becomes idle and are repeated until the arrival of an external disk request. Type one (two) vacations correspond to the reading of the first track which requires a seek (successive tracks requiring no seeks). The analytic solution is used to quantify the effect of different rebuild options, such as read redirection and the split-seek option.>

Presents a novel method, called EVENODD, for tolerating up to two disk failures in RAID architectures. EVENODD is the first known scheme for tolerating double disk failures that is optimal with regard to both storage and performance. EVENODD employs the addition of only two redundant disks and consists of simple exclusive-OR computations. A major advantage of EVENODD is that it only requires parity hardware, which is typically present in standard RAID-5 controllers. Hence, EVENODD can be implemented on standard RAID-5 controllers without any hardware changes. The only previously known scheme that employs optimal redundant storage (i.e. two extra disks) is based on Reed-Solomon (RS) error-correcting codes, requires computation over finite fields and results in a more complex implementation. For example, the authors show that the number of exclusive-OR operations involved in implementing EVENODD in a disk array with 15 disks is about 50% of the number required when using the RS scheme.>

RAID-5 arrays need 4 disk accesses to update a data block—2 to read old data and parity, and 2 to write new data and parity. Schemes previously proposed to improve the update performance of such arrays are the Log-Structured File System [10] and the Floating Parity Approach [6]. Here, we consider a third approach, called Fast Write, which eliminates disk time from the host response time to a write, by using a Non-Volatile Cache in the disk array controller. We examine three alternatives for handling Fast Writes and describe a hierarchy of destage algorithms with increasing robustness to failures. These destage algorithms are compared against those that would be used by a disk controller employing mirroring. We show that array controllers require considerably more (2 to 3 times more) bus bandwidth and memory bandwidth than do disk controllers that employ mirroring. So, array controllers that use parity are likely to be more expensive than controllers that do mirroring, though mirroring is more expensive when both controllers and disks are considered.

Abstract The HAGAR project is building a high‐performance disk controller. It is an embedded system for which many hundreds of thousands of lines of embedded software will have to be developed concurrently with the development of the hardware. We found existing methods for embedded software development, such as simulation and remote cross development, to be inadequate for us. To meet our special needs, we developed a distributed development environment that combines and extends the capabilities of existing methods while fixing their drawbacks. Our environment is based on a processor‐pool architecture, in which multiple hardware sets are pooled and managed systematically. It supports embedded software development for many programmers at different sites. It allows for the emulation of non‐existing hardware adaptor cards and for the integration of embedded software testing with hardware simulation. The environment provides a single system image, hiding many hardware and configuration details from its users. From the perspective of the programmers, our environment makes developing embedded software for special hardware systems as easy as developing application programs for a UNIX workstation.

Analytical models for evaluating the performance of arrayed disk subsystems in normal, degraded, and rebuild mode are developed. Models for estimating rebuild time under the assumption that user requests get priority and can preempt rebuild activity are also developed. It is found that uncached disk arrays perform much worse than uncached nonarrays. It is determined that caches are necessary in arrayed subsystems. Furthermore, in degraded and rebuild modes, large building blocks minimize the worst response time seen by any user, whereas small building blocks minimize the average response time.>

This paper explores how choice of sparing methods impacts the performance of RAID level 5 (or parity striped) disk arrays. The three sparing methods examined are dedicated sparing, distributed sparing, and parity sparing. For database type workloads with random single block reads and writes, array performance is compared in four different modes - normal mode (no disks have failed), degraded mode (a disk has failed and its data has not been reconstructed), rebuild mode (a disk has failed and its data is being reconstructed), and copyback mode(which is needed for distributed sparing and parity sparing when failed disks are replaced with new disks). Attention is concentrated on small disk subsystems (fewer than 32 disks) where choice of sparing method has significant impact on array performance, rather than large disk subsystems (64 or more disks). It is concluded that, for disk subsystems with a small number of disks, distributed sparing offers major advantages over dedicated sparing in normal, degraded and rebuild modes of operation, even if one has to pay a copyback penalty. Furthermore, it is better than parity sparing in rebuild mode and similar to it in other operating modes, making it the sparing method of choice.

Traditional database systems have long been plagued by performance problems when there is either an increase in the mainframe usage or in the database applications. Solutions to these problems have been sought, first, by offloading the database system from the mainframe computer to a single, dedicated backend computer. The backend computer has its own disk storage, is used to perform all of the database operations, and interacts with the mainframe. However. database systems with this software single-backend approach still encounter the performance problems when either the backend usage or database applications increase. The software multiple-backend approach to database management and hardware upgrade is therefore proposed to overcome the performance-gains and capacity-growth problems of either traditional mainframe-based database systems or conventional software single-backend database systems. In this paper we specify the design requirements and issues of the software multi-backend database systems. We show how these requirements and issues affect the design and implementation of a multi-backend database system known as MBDS. Since MBDS is designed specifically for performance gains, capacity growth, and hardware upgrade, we benchmark MBDS in order to verify whether its design and implementation can indeed relate the gains and growth directly to the multiplicity of backends in terms of the response-time reduction and invariance.