Abstract
Solid-state drives (SSDs) have accelerated the architectural evolution of storage systems with several characteristics (e.g., out-of-place update) compared with hard disk drives (HDD). Out-of-place update of SSDs naturally can support transaction mechanism which is commonly used in systems to provide crash consistency. Thus, transactional functionality has been recently implemented inside solid-state drives (SSDs). However, this approach must be re-evaluated for enterprise storage with a standard interface to investigate their benefits in a more realistic and standard fashion. In this article, we explore the implications and challenges of transactional SSDs with different experiments. To evaluate the potential benefit of transactional SSDs, we design and implement the transactional functionality in a Samsung enterprise-class and SATA-based SSD (i.e., SM843TN) called TxSSD. We modify the local file systems (i.e., ext4 and btrfs) and a distributed parallel file system (i.e., Lustre) to utilize TxSSDs. Our modified file systems with TxSSDs provide crash consistency without redundant writes. We evaluate our file systems by using multiple micro and macro benchmarks. We analyze the performance results and demonstrate that TxSSDs may generate an overhead for supporting transactional functionality inside SSD.
Highlights
Flash memory is widely used for storage devices from single to large-scale high performance systems since it provides lower latency, lower power consumption, and higher throughput than hard disk drives (HDDs) [5], [43]
We focus on the performance for transactional solid-state drives (SSDs) based on SATA and the firmware flash translation layer (FTL) rather than a host-based FTL that consumes host resources
In this article, we investigated the implications of transactional SSDs
Summary
Flash memory is widely used for storage devices from single to large-scale high performance systems since it provides lower latency, lower power consumption, and higher throughput than hard disk drives (HDDs) [5], [43]. The writeback mode supports transaction processing only for metadata writes. This mode does not keep the write order between the metadata and data. The data journaling mode performs transaction processing for both metadata and data. It writes both metadata and data to the journal location before they are written to the original location. This mode supports the strongest consistency with data integrity (crash consistency). It shows the lowest performance because of redundant data writes
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
