July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here



File Systems and Storage

  Download PDF version of this article PDF

Error 526 Ray ID: 46de14793f8991d6 • 2018-10-22 18:38:16 UTC

Invalid SSL certificate

You

Browser

Working
Newark

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

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


Tweet



Related:

Pat Helland - Mind Your State for Your State of Mind
The interactions between storage and applications can be complex and subtle.


Alex Petrov - Algorithms Behind Modern Storage Systems
Different uses for read-optimized B-trees and write-optimized LSM-trees


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



Comments

(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.