

Why SATA is now obsolete - mrkd
http://www.zdnet.com/article/why-ssds-are-obsolete/
Article based on paper:
http:&#x2F;&#x2F;research.cs.wisc.edu&#x2F;adsl&#x2F;Publications&#x2F;yiying-thesis13.pdf
======
KaiserPro
"why maintain two logical address spaces? Why not have the file system
directly manage the flash?"

Because managing flash is hard. For this to work, the amount of exceptions in
the filesystem it's self would make it unmanageable.

an example is this: a Fusion-io card up until recently used low quality flash,
yet managed to get stella performance. Much higher performance than the
equivalent intel ssd card (who have access to much higher quality flash) some
of that is down to layout, the rest firmware.

Then you have the flash that lives on a device like your phone, however the
firmware of the SoC is tweaked to run that particular flash controller.

At its heart, flash/hdd is just a key:value database (presented with 4k value
size) why would we want to complicate that (sure we need to indicate to the
hardware that we've deleted a page, but to be honest not much else)

~~~
stupidcar
It seems like the article maybe misrepresents what the thesis that inspired it
says[1]. From the abstract:

"... the device still has its freedom to control block-allocation decisions,
enabling it to execute critical tasks such as garbage collection and wear
leveling ... Next, we present Nameless Writes, a new device interface that
removes the need for indirection in flash-based SSDs. Nameless writes allow
the device to choose the location of a write; only then is the client informed
of the name (i.e., address) where the block now resides."

So it sounds like this approach is actually removing responsibility from the
filesystem, not the firmware.

[1] [http://research.cs.wisc.edu/adsl/Publications/yiying-
thesis1...](http://research.cs.wisc.edu/adsl/Publications/yiying-thesis13.pdf)

~~~
Peaker
Nameless writes save an indirection layer -- but quite a cheap one!

They add significant latency to write operations, though, which is a high
price to pay for such a small gain.

~~~
Gurkenmaster
SSDs are so fast let's make them slow again!

------
mrkd
Article based on paper: [http://research.cs.wisc.edu/adsl/Publications/yiying-
thesis1...](http://research.cs.wisc.edu/adsl/Publications/yiying-thesis13.pdf)

~~~
gwern
"De-indirection for Flash-based Solid State Drives", Zhang 2013
[http://research.cs.wisc.edu/adsl/Publications/yiying-
thesis1...](http://research.cs.wisc.edu/adsl/Publications/yiying-thesis13.pdf)

"Flash-based solid-state drives (SSDs) have revolutionized storage with their
high performance. Modern flash-based SSDs virtualize their physical resources
with _indirection_ to provide the traditional block interface and hide their
internal operations and structures. When using a file system on top of a
flash-based SSD, the device indirection layer becomes redundant. Moreover,
such indirection comes with a cost both in memory space and in performance.
Given that flash-based devices are likely to continue to grow in their sizes
and in their markets, we are faced with a terrific challenge: _How can we
remove the excess indirection and its cost in flash-based SSDs?_

We propose the technique of de-indirection to remove the indirection in
flashbased SSDs. With de-indirection, the need for device address mappings is
removed and physical addresses are stored directly in file system metadata. By
doing so the need for large and costly indirect tables is removed, while the
device still has its freedom to control block-allocation decisions, enabling
it to execute critical tasks such as garbage collection and wear leveling.

In this dissertation, we first discuss our efforts to build an accurate SSD
emulator. The emulator works as a Linux pseudo block device and can be used to
run real system workloads. The major challenge we found in building the SSD
emulator is to accurately model SSDs with parallel planes. We leveraged
several techniques to reduce the computational overhead of the emulator. Our
evaluation results show that the emulator can accurately model important
metrics for common types of SSDs, which is sufficient for the evaluation of
various designs in this dissertation and in SSD-related research.

Next, we present _Nameless Writes_ , a new device interface that removes the
need for indirection in flash-based SSDs. Nameless writes allow the device to
choose the location of a write; only then is the client informed of the _name_
(i.e., address) where the block now resides. We demonstrate the effectiveness
of nameless writes by porting the Linux ext3 file system to use an emulated
nameless-writing device and show that doing so both reduces space and time
overheads, thus making for simpler, less costly, and higher-performance SSD-
based storage.

We then describe our efforts to implement nameless writes on real hardware.
Most research on flash-based SSDs including our initial evaluation of nameless
writes rely on simulation or emulation. However, nameless writes require
fundamental changes in the internal workings of the device, its interface to
the host operating system, and the host OS. Without implementation in real
devices, it can be difficult to judge the true benefit of the nameless writes
design. Using the OpenSSD Jasmine board, we develop a prototype of the
Nameless Write SSD. While the flash-translation layer changes were
straightforward, we discovered unexpected complexities in implementing
extensions to the storage interface.

Finally, we discuss a new solution to perform de-indirection, the File System
De-Virtualizer ( _FSDV_ ), which can dynamically remove the cost of
indirection in flash-based SSDs. FSDV is a light-weight tool that de-
virtualizes data by changing file system pointers to use device physical
addresses. Our evaluation results show that FSDV can dynamically reduce
indirection mapping table space with only small performance overhead. We also
demonstrate that with our design of FSDV, the changes needed in file system,
flash devices, and device interface are small."

------
Animats
The author is on to something. Flash memory devices can emulate disks, but
that's an inefficient way to access them, especially for reading. You have all
the overhead of Linux system calls and file systems to, basically, read a RAM-
like device that's orders of magnitude faster in access time than a rotating
device.

The question is, what non-file abstraction should a flash device offer? Slow
persistent RAM? A key/value store? An SQL database? Computing has had "RAM"
and "disks" as its storage models for so long that those concepts are nailed
into software at a very low level.

The NoSQL crowd could probably find uses for devices that implemented big,
fast key/value stores.

~~~
dfox
The problem with NAND flash is that it is not "RAM-like device" even for reads
(smallest addressable entity is block even for reads).

It can essentially do three operations: read block, write block, erase bunch
of blocks at once. For the purposes of filesystem, this is actually an
workable storage interface that does not need any additional abstraction
layers.

~~~
robotresearcher
You are both right. It's a RAM-like key-value store with large (block-sized)
values.

~~~
Peaker
It's not RAM-like, because you can read small parts of keys, but have to write
large ones.

~~~
robotresearcher
You can't read or write individual bits or bytes in RAM directly either. Word
size is very small compared to disk blocks, but it's not atomic.

I'm not an architecture expert, so please correct me if I'm wrong about this.

~~~
__david__
It depends on what kind of RAM and what kind of bus you are using. Some do let
you write bytes at a time, others only allow N byte words at a time.

Though I suppose a byte is still not a bit! I'm not sure I've ever seen a bus
interface that addressed individual bits…

~~~
Peaker
But the read and write are symmetric, of same sizes.

~~~
__david__
No: some buses let you write different sized words to the memory controller or
RAM chip. For example, picture a bus that's 32 bits wide, but there are
control lines that let you specify that you're writing (or reading) 1 byte, 2
bytes, or 4 bytes. During a single byte wide bus cycle you are _not_ sending 4
bytes to the part, even though there are 32 bits connecting to it.

Certainly not everything out there is byte addressable, but neither can one
say unequivocally that all RAMs have large atomic word sizes.

~~~
Peaker
Again, in your scenario read&write are symmetric. In Flash, they're not.

~~~
__david__
I don't understand what you mean by "symmetric". If I can write a 32 bit word
out and read 1 byte of it back, I don't consider that "symmetric".

------
ebbv
It sounds like a great idea to "get rid of abstraction" and have the file
system handle the NAND directly if you don't think about it.

But if you think about it for even a little bit you realize that you can't
just get rid of the abstraction, you're just moving it out of the drive's
firmware and into the file system. And that gets you nothing because now the
file system has to be compatible with every manufacturer's NAND drives. And
the file system has to be updated any time that system needs to be changed.
You can't just pop a new NAND drive in and have it work, you have to download
new NAND drivers for the file system, etc.

I'm also skeptical of just how much performance gain you'd see. The article
doesn't include these figures, which makes me skeptical that they are
significant.

Delegation of duties is important for good system design. Drives necessarily
need to present themselves in a standard way to the system. Having SSDs appear
like normal drives is fine. They aren't memory and they shouldn't be used as
memory.

~~~
sanxiyn
Flash Translation Layer _is_ critical to performance. Googling "flash
translation layer performance" should be enough to convince you of this.

Moving it from firmware to file system does not improve performance by itself,
but it enables optimizations. And FTLs in firmware are far from optimal.

------
jkot
> _The obvious question is: why maintain two logical address spaces?_

There are perhaps 10 more address spaces and translations. It the way OS and
hardware are build.

> _Why not have the file system directly manage the flash?_

Too slow innovation, it takes decade to replace operating system. Also main
CPU is very power hungry and slow...

More likely the SSD controller will become part of CPU and SOC.

------
stcredzero
_now that non-volatile memory technology - flash today, plus RRAM tomorrow -
has been widely accepted, it is time to build systems that use flash directly
instead of through our antique storage stacks._

Hear hear! The basic storage model that arose in the 50's and 60's being the
best fit for recently developed hardware seems as likely as the security
models from the 50's and 60's being the best fit for the Internet.

(If the obnoxious popup adverts from ZDNet strike _me_ as archaic, they are
not doing well.)

~~~
jschwartzi
If NAND continues to function the way it does today, we would still need to
standardize on some kind of interface to get traction. The advantage of SATA,
SAS, PCIe, et. al. are their pervasiveness in the PC world. His proposal
basically boils down to "NAND on SATA is kinda slow because of all the latency
from stuff. We should just hook the NAND up to one of the upstream buses."
It's unclear to me how this is different from what is already being done.

------
rwmj
If you're interested in this subject from a Linux/storage expert, here's Ric
Wheeler's talk from FOSDEM last year:
[https://archive.fosdem.org/2014/schedule/event/persistent_me...](https://archive.fosdem.org/2014/schedule/event/persistent_memory/)

------
danbruc
One word. Separation of concerns. Okay, three. Why would you want to mix
managing files and transistors?

------
vortico
I like "news" articles like this. Harris takes a scientific publication, adds
his own opinion while making the topic easier to understand, and cites his
source.

~~~
elif
Personally, i believe his armchair dismissal of FTL requires far more
justification than he gives. This blog post is pure postulation that doesn't
even attempt to take up the argument of the dissertation, let alone take that
argument far enough to justify that title.

In fact in the thesis' abstract, the proposed solution is still a layer of
indirection. Instead of the FTL giving an abstracted address space, the
"device" is given the responsibility of controlling wear, gc, and parallelism
by dynamically reallocating blocks itself, and the filesystem picking up some
more of the management stuff.

I am certainly not qualified enough to read this dissertation critically
enough to know if it is fundamentally sound theoretically, but as a scientist
I know that it is close to meaningless until it has been experimentally tested
and reviewed..

------
lbenes
As a related note, if you upgrade to a SSD be sure to change the SATA type in
BIOS from IDE to AHCI. Not only did I see a doubling in write speed [1], but
after making the change, my system felt much more responsive under heavy load.

[1] [http://forum.crucial.com/t5/Crucial-SSDs/Why-do-i-need-
AHCI-...](http://forum.crucial.com/t5/Crucial-SSDs/Why-do-i-need-AHCI-with-a-
SSD-Drive-Guide-Here-Crucial-AHCI-vs/td-p/57078)

------
gumby
Basically the author is calling for a return to the Multics file system, where
files were just a way of referring to capability-managed subsets of an
enormous pool of pages.

I liked the idea the first time around so I like it again. But it's harder
than it sounds.

I find something lovely and poetic in the fact that Lisp is over 50 years old
and Multics is almost that old, and both may be having a bit of a renaissance.

------
jwatte
Yes, the SATA interface to flash storage is obsolete. Just like internal
combustion engines! And it will be almost as hard to get rid of.

~~~
wtallis
SATA and AHCI are already on their way out, being replaced by PCIe and NVMe.
That removes most of the abstraction that is actually obsolete, but it doesn't
pretend that SSDs aren't fundamentally block devices. About the only thing
NVMe does that is perpetuating a fiction about the underlying flash is that
the read block size and write block size are the same thing. All the rest is
abstraction that's absolutely _necessary_ until we completely change our
conventions for computer architecture and operating systems.

------
blt
Linkbait title is linkbait, but content is sound.

------
jordanpg
I'm not a hardware expert, but my intuition tells me that the general thesis
-- that any given hardware module _could be_ implemented in some way that's
light years ahead of where we are now -- is often true. But there is more to
widespread adoption than being the best technology: marketing, timing,
industrial realities, legacy software limitations... Legacy enterprise
software and OSs in particular seem they probably make significant
architectural changes to the very core of every computer difficult to effect.

------
rocky1138
This isn't an entirely novel idea. I remember in 2009 Steve Wozniak giving a
talk in Waterloo about becoming the Chief Scientist for Fusion-io
([https://fusionio.com/](https://fusionio.com/)), a company building PCI-E
SSDs, bypassing the SATA bus.

~~~
pyromine
This is somewhat tangential, but my professor recruited Steve to come to
Fusion-io and always speaks incredibly highly of Steve. When he was leaving
the CEO position to give it back to the founder of Fusion-io he offered Steve
some additional shares and Steve told him to give the shares the engineers who
actually produce the technology. Incredible humbleness there.

------
zobzu
all he means behind the sensationalistic crap is that the sata controller is
not actually needed, its there for compatibility.

"hard disk" will not be the ram. its just is made of the same chips, but still
logically separated. and there is no need for a sata controller to address it
really.

That's all. You still need a file system if you want to address the files.
Just like address blocks of ram or anything else. If you give free reign to
the app, there is no security, reliability, etc. Even ram is actually indexed
as well.

On top of that you need a representation for the human behind it - no matter
how hard they try to remove that (because its much easier to lock you in when
there is no generic way to browser a memory device), its not very convenient
compared to a file system.

------
sp332
That sounds fine in principle, but please don't tell me the future is jffs2!

~~~
wmf
I think the proposal is something like ZFS/Btrfs but with even more complexity
to handle wear leveling and such.

~~~
etcet
Is this going to have a net benefit? To my mind it makes more sense for
specialized functionality to be built into the drives firmware rather than
letting the CPU deal with it.

------
duckingtest
My SSD has a three core cpu dedicated to it. Removing the layer of indirection
isn't going to make it faster. At best it's going to make the ssd cheaper by a
minuscule amount due to a simpler controller.

~~~
wmf
One core of your main processor is faster than those three embedded cores;
that's why Fusion-io mooches off the main processor.

~~~
duckingtest
Its probably fast enough for its purpose. If it isn't, making it faster is way
easier than changing existing abstraction layers. In the extreme, it can ever
be an asic.

------
markhahn
the basic premise is that remapping is necessarily expensive. unfortunately,
neither the thesis nor its citations really support that. and we have plenty
of examples where remapping is pervasive and apparently efficient (MMUs, for
instance). it's hard to imagine how a filesystem could reasonably handle wear-
levelling, not to mention the now-common practice of using MLC cells to hold
SLC data for faster writes, etc.

the "nameless writes" idea is OK - a FS person would just call it even lazier
allocation, not anything really different.

------
mark-r
I've always wondered how much performance gain you could get if the very large
blocks required for erasure were known to the file system, rather than being
hidden behind an emulation layer.

------
markbnj
I think the author misunderstands the word "obsolete." Something is only
obsolete when there is something better to replace it with.

------
WaxProlix
Anyone else think it's a little ironic to read about something being obsolete
on ZDNet?

------
Someone1234
The title is odd. Should be "Why SATA is now obsolete."

The article is of course correct, and some manufacturers are already offering
SSD-like storage which is connected like a stick of RAM.

I'm sure the gap between storage and the main system pipeline (CPU-GPU-RAM-
etc) will only shrink as time moves forward. However as an interim solution
things that acted like hard drives were convenient.

~~~
cryptophreak
Yes, but if the title was honest then not as many people would click, and we
can’t have that.

~~~
kleer001
and that's exactly why I read the comments first

