Distributed storage system mush keep data available against several hardware/software failures. To achieve this, conventional distributed storage systems employ replication which is a simple but effective method to make distributed storage systems resilient. However, replicating a significant amount of data incurs substantial storage overheads. Therefore, erasure coding becomes an alternative to replication as it can offer the same reliability as or higher reliability than triple replication (denoted by “3-replication”), with much lower storage overheads. The Reed-Solomon (RS) code is one of the most popular erasure code due to its optimal storage space utilization. When an RS code is employed, all input data are stored as chunks with a fixed size. In general, RS(k,m) computes m numbers of coding chunk for k numbers of the data chunk, and the system distributes the data and coding chunks across different storage devices or nodes. For example, RS(6,3) splits original data into six data chunks and generates additional three coding chunks.

The Environment of Trace Collection

These traces are collected from each system employing 3-replication, RS(6,3), RS(10,4). Every workload is generated by Flexible I/O tester (FIO). RS(6,3) and RS(10,4) are generally employed by real industry such as Google Colossus and Facebook HDFS, respectively. Our Ceph cluster consists of 24 OSDs; therefore, 24 traces are collected for each workload.

Trace File Format

Traces are represented in the default format. From left to right, each column represents “the event's device major/minor”, “CPU ID”, “sequence number”, “timestamp (sec)”, “process ID”, “I/O status (ex. complete, issued, bounced…)”, “RWBS”, “starting block address”, “number of blocks”, “process”.