Programming Storage Controllers with OX

ion for modifying FTLs. In the rest of this paper, we present the lessons we learnt programming a SoC-Based front-end to Open-Channel SSDs. More specifically, we present the abstract execution model corresponding to the mapping between application-specific commands and the physical address space exposed by Open-Channel SSDs. We adopt an approach where code is compiled and installed on the SoC. We present the OX template that we specialized for different applications. 3 ABSTRACT EXECUTION MODEL We propose an abstract execution model for mapping commands defined on an application-specific address space onto storage commands on a physical address space. Figure 1 represents this abstract execution model that consists of 3 layers sandwiched between an NVMe controller exposed to the host, via fabrics, and an NVMe driver connected to one or several Open-Channel SSDs. We are currently evaluating how NVMe over fabrics compares to applicationlevel RPC, e.g., gRPC, as host-interface. Our assumption is that NVMe provides higher performance which is key on the dataplane. The 3 layers of the abstract execution model are (i) a parser adapted to the application specific commands and address space, (ii) an FTL responsible for the logical-physical mapping and the associated tasks of meta-data management, garbage collection and recovery, and (iii) a standard module for dispatching the commands generated by the FTL to the NVMe driver. Because of space limitation, we limit ourselves to remarks about the role of the queues in this model. The storage controller is asynchronous in nature. It relies on a decoupling of command submission and notification of completion. Queues are the natural way to structure flows of submission/completions both at the interface between the storage controller and its environment, and within the FTL at the heart of the mapping between logical and physical representations. 4 FTL PROGRAMMINGWITH OX Pblk represents the first robust open-source implementation of an FTL. It is part of the Linux kernel [6]. Therefore, it naturally supports file systems. It must remain generic and robust. It is not meant to be modified to support application-specific address spaces. As a result, we designed and implemented a version of pblk in userspace. This FTL is denoted OX2. It adopts the modular structure of pblk. OX is designed as an FTL template, that can be readily modified to program storage controllers. Figure 2 shows the OX architecture (including dependencies across modules) as well as the data path for both user and controller generated data movement. We represent API calls as generic reads or writes, even specialized calls are defined in practice. The OX FTL is composed of nine modules. We specialized it for two different applications: a log store and an LSM-Tree store. The log store defines each log flush as a transaction boundary. This impacts the write caching and checkpoint/recovery modules. The LSM-tree 2https://github.com/DFC-OpenSource/ox-ctrl/wiki Figure 2: ox controller architecture store modifies garbage collection so that it implements LSM-Tree compaction, as well as block provisioning where we experiment with various data placement policies. In both cases, we modified command parser and mapping table, while the bad block management module remained unchanged. A thorough analysis of OX specialisation is a topic for future work. It is already obvious though that there is a need for tools to help check FTL correctness and debug concurrency bugs. In addition, there might be opportunities for developing languages that guide OX specialisation, e.g., the decomposition and mapping of values from the logical to the physical address space.