· by Aldrin Montana
The authors are trying to address the difficulty of adapting existing storage systems to both: special-purpose data processing applications and rapidly evolving storage devices.
There are not many other projects attempting to solve the same problem. There are some high-level similarities with software defined storage and software defined networks, but only in the sense that new abstractions are a way of developing new policies on top of existing mechanisms. Separation of policies and mechanisms to achieve this type of flexibility is an important aspect of operating systems and other systems-level areas of work.
Although not mentioned in the paper, there are many implementations, or mechanisms, that enable programmable storage approaches. Namely, mechanisms such as the virtual object layer in the HDF5 file format. While we can’t speak to the intent of developers that have worked on these mechanisms, the concept of exploring these types of mechanisms for extensive re-use and research in composability seems to be precise enough that it is not being specifically pursued any other group.
The authors claim their approach is, “to expose more of the commonly used, code-hardened subsystems of the underlying storage system as interfaces.” This approach is distinct from other approaches because it attempts to explore the reusability of subsystems which are well-vetted. This can be a better approach for complex use cases where it can be hard to write performant, correct low-level code. But this approach requires a certain amount of creativity in how existing subsystems or mechanisms can be composed to provide specific functionality. It can be quite difficult for developers to create, and especially maintain, new interfaces from existing code.
Evaluation of CORFU compared to zlog (implementation of CORFU in malacology) is not provided by the malacology paper, but can somewhat be understood by looking at the performance provided in the 2 papers. Note, however, that while CORFU specifies the environment for their evaluation (32 networked Intel X25V drives, 2 racks of 8 servers with 2 drives each and 11 clients), the malacology paper does not seem to.
For 11 clients and 8 2-drive servers, CORFU is able to achieve a peak read throughput of ~375k operations per second and a peak write throughput of ~150k operations per second. For 2 clients and many OSDs (usually 1 OSD per disk, and a later experiment has 120 OSDs, though the throughput experiment does not specify the number of OSDs), zlog has a peak throughput of 1.2 million operations per second, if clients are allowed a quota of 1000000 operations before relinquishing an exclusive lease on the sequencer. WIth a quota of 1 operation on the exclusive lease, zlog has a peak throughput of ~100k operations per second. The biggest difficulty in comparing these evaluations is that it is not known what the maximum throughput is for zlog with a higher client load, nor is it known how many disks are being used.
This work is important because it seems to be the first to research in the specific area of programmable storage. Specifically, it uses composability of system mechanisms to address increasing momentum at the application layer and hardware layer in a way that maintains a significant amount of reliability, yet provides various, powerful interfaces and abstractions.