endurance. It further extends the original parity logging design
by allowing parity chunks to be computed based on the newly
written data chunks only, where the data chunks may span
within a partial stripe or across more than one stripe. Such an
“elastic” parity construction eliminates the need of pre-reading
old data for parity computation, so as to improve performance.
To summarize, this paper makes the following contributions:
• We design and implement EPLOG as a user-level
block device
1
that manages an SSD RAID array.
Specifically, EPLOG uses hard-disk drives (HDDs)
to temporarily log parity information, and regularly
commits the latest parity updates to SSDs to mitigate
the performance overhead due to HDDs. We show
that EPLOG enhances existing flash-aware SSD RAID
(see Section VI) in different ways: (i) EPLOG is
fully compatible with commodity configurations and
does not rely on high-cost components such as non-
volatile RAM (NVRAM); and (ii) EPLOG can readily
support general erasure coding schemes for high fault
tolerance.
• We conduct mathematical analysis on the system reli-
ability in terms of mean-time-to-data-loss (MTTDL).
We show that EPLOG improves the system reliability
over the conventional RAID design when SSDs and
HDDs have comparable failure rates [48].
• We conduct extensive trace-driven testbed experi-
ments, and demonstrate the endurance and perfor-
mance gains of EPLOG in mitigating parity update
overheads. We compare EPLOG with the Linux soft-
ware RAID implementation based on mdadm [37],
which is commonly used for managing software RAID
across multiple devices. For example, in some settings,
EPLOG reduces the total write traffic to SSDs by
45.6-54.9%, reduces the number of GC requests by
77.1-97.6%, and increases the I/O throughput by 30.1-
119.2% even though it uses HDDs for parity logging.
Finally, EPLOG shows higher throughput than the
original parity logging design, and incurs low over-
head in metadata management.
The rest of the paper proceeds as follows. In Section II,
we state our design goals and motivate our new elastic parity
logging design. In Section III, we describe the design and
implementation details of EPLOG. In Section IV, we analyze
the system reliability of EPLOG. In Section V, we present
evaluation results on our EPLOG prototype through trace-
driven testbed experiments. In Section VI, we review related
work, and finally in Section VII, we conclude the paper.
II. OVERVIEW
In this section, we state the design goals of EPLOG. We
also motivate how EPLOG mitigates parity update overhead
through elastic parity logging.
A. Goals
EPLOG aims for four design goals.
1
Here, a block refers to the read/write unit at the system level, and should
not be confused with an SSD block at the flash level.
• General reliability: EPLOG provides fault tolerance
against SSD failures. In particular, it can tolerate
a general number of SSD failures through erasure
coding. This differs from many existing SSD RAID
designs that are specific for RAID-5 (see Section VI).
• High endurance: Since parity updates introduce extra
writes to SSDs, EPLOG aims to reduce the parity traf-
fic caused by small (or partial-stripe) writes to SSDs,
thereby improving the endurance of SSD RAID.
• High performance: EPLOG eliminates the extra
I/Os due to parity updates, thereby maintaining high
read/write performance.
• Low-cost deployment: EPLOG is deployable using
commodity hardware, and does not assume high-
end components such as NVRAM as in SSD RAID
designs (e.g., [10], [15], [26]).
EPLOG targets workloads that are dominated by small
random writes, leading to frequent partial-stripe writes to
RAID. Examples of such workloads include those in database
applications [17], [27] and enterprise servers [20]. Note that
real-world workloads often exhibit high locality both spatially
and temporally [34], [43], [46], such that recently updated
chunks and their nearby chunks tend to be updated more
frequently. It is thus possible to exploit caching to batch-
process chunks in memory to boost both endurance and
performance (by reducing write traffic to SSDs). On the other
hand, modern storage systems also tend to force synchronous
writes through fsync/sync operations [14], which make
small random writes inevitable. Thus, our baseline design
should address synchronous small random writes, but allows
an optional caching feature for potential performance gains.
B. Elastic Parity Logging
Parity logging [47] has been a well-studied solution in
traditional RAID to mitigate the parity update overhead. We
first review the design of parity logging, and then motivate
how we extend its design in the context of SSD RAID.
We first demonstrate how parity logging can improve
endurance of an SSD RAID array by limiting parity traffic to
SSDs. Our idea is to add separate log devices to keep track of
parity information that we refer to as log chunks. To illustrate,
Figure 1 shows an SSD RAID-5 array with three SSDs for
data and one SSD for parity (i.e., the array can tolerate single
SSD failure). In addition, we have one log device for storing
log chunks. Suppose that a stream of write requests is issued
to the array. The first two write requests, respectively with data
chunks {A0, B0, C0} and {A1, B1, C1}, constitute two stripes.
Also, the following write request updates data chunks B0,
C0, and A1 to B0’, C0’, and A1’, respectively. Figure 1(a)
illustrates how the original parity logging works. It updates
data chunks in-place at the system level above the SSDs (note
that an SSD adopts out-of-place updates at the flash level as
described in Section I-A). It computes a log chunk by XOR-
ing the old and new data chunks on a per-stripe basis. It then
appends all log chunks to the log device.
The original parity logging limits parity traffic to SSDs,
thereby slowing down their wearing rates. Nevertheless, we