January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

File Systems and Storage

  Download PDF version of this article PDF

ITEM not available


Originally published in Queue vol. 11, no. 3
see this item in the ACM Digital Library



Mihir Nanavati, Malte Schwarzkopf, Jake Wires, Andrew Warfield - Non-volatile Storage
Implications of the Datacenter's Shifting Center

Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, Samer Al-Kiswany, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau - Crash Consistency
Rethinking the Fundamental Abstractions of the File System

Michael Cornwell - Anatomy of a Solid-state Drive
While the ubiquitous SSD shares many features with the hard-disk drive, under the surface they are completely different.

Marshall Kirk McKusick - Disks from the Perspective of a File System
Disks lie. And the controllers that run them are partners in crime.


(newest first)

Steven Grimm | Mon, 22 Apr 2013 03:40:33 UTC

How close to optimal can you even get with the existing filesystem APIs at the application level? That seems like an even more fundamental limitation that you can't address by getting rid of the FTL. An application using typical user-level filesystem APIs currently has no good way to tell the system that it expects to be doing a lot of random-access writes or even, to use one example from the article here, that the write it's doing is actually just an unmodified copy of a portion of another file.

Is it possible that maximizing the performance gains requires changes to the application-to-filesystem interface rather than just the filesystem-to-device interface?

I was, I admit, slightly disappointed to not see this article attempt to quantify the potential performance wins here. Presumably it won't matter too much for a workload consisting mostly of large sequential reads, but how big are the potential wins for other kinds of workloads?

John Martin | Wed, 17 Apr 2013 12:10:19 UTC

-Disclosure NetApp Employee though not posting as a representative, these comments/opinions are my own, and not to be construed as indicative of NetApp policy, or future technical direction. -

I think there are three main choices for filesystem designers working with Flash, and none of them IMHO are ideal

a) bypass the FTL entirely (as NetApp did with Flashcache) and use a data structure directly on top of raw flash disks b) try to identify an FTL that works reasonably harmoniously with what you already have or can develop in a reasonable timeframe (as NetApp did with FlashPool) c) develop something that is completely at the mercy of the underlying FTL and let the customer choose (as NetApp did with FlashAccel)

What isn't readily available today is a programmable FTL within an SSD package that allows you to give hints/instructions to it to change the way it lays out data in the way an openflow controller manages flow tables within a switch. From my perspective that would be an attractive middle ground, allowing filesystem designers to concentrate on things that could be reasonably run on commodity CPU cycles while allowing the SSD/ASIC/FPGA vendors to innovate and compete doing what they do best.

It introduces more complexity than the current "black box SCSI target", but I think the benefits of an ASIC/FPGA driven FTL are pretty well established and with some reasonable open standards I believe that filesystem designers working co-cooperatively with the SSD vendors would drive much faster innovation than going it alone.

I once read that Mathematicians stand on the shoulders of Giants, where IT guys tend to tread on each other toes ... I think we can be better than that.

Regards John Martin storagewithoutborders.com

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.