"why maintain two logical address spaces? Why not have the file system directly manage the flash?"<p>Because managing flash is hard. For this to work, the amount of exceptions in the filesystem it's self would make it unmanageable.<p>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.<p>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.<p>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)
Article based on paper:
<a href="http://research.cs.wisc.edu/adsl/Publications/yiying-thesis13.pdf" rel="nofollow">http://research.cs.wisc.edu/adsl/Publications/yiying-thesis1...</a>
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.<p>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.<p>The NoSQL crowd could probably find uses for devices that implemented big, fast key/value stores.
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.<p>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.<p>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.<p>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.
> <i>The obvious question is: why maintain two logical address spaces?</i><p>There are perhaps 10 more address spaces and translations. It the way OS and hardware are build.<p>> <i>Why not have the file system directly manage the flash?</i><p>Too slow innovation, it takes decade to replace operating system. Also main CPU is very power hungry and slow...<p>More likely the SSD controller will become part of CPU and SOC.
<i>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.</i><p>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.<p>(If the obnoxious popup adverts from ZDNet strike <i>me</i> as archaic, they are not doing well.)
If you're interested in this subject from a Linux/storage expert, here's Ric Wheeler's talk from FOSDEM last year:
<a href="https://archive.fosdem.org/2014/schedule/event/persistent_memory/" rel="nofollow">https://archive.fosdem.org/2014/schedule/event/persistent_me...</a>
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.
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.<p>[1] <a href="http://forum.crucial.com/t5/Crucial-SSDs/Why-do-i-need-AHCI-with-a-SSD-Drive-Guide-Here-Crucial-AHCI-vs/td-p/57078" rel="nofollow">http://forum.crucial.com/t5/Crucial-SSDs/Why-do-i-need-AHCI-...</a>
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.<p>I liked the idea the first time around so I like it again. But it's harder than it sounds.<p>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.
I'm not a hardware expert, but my intuition tells me that the general thesis -- that any given hardware module <i>could be</i> 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.
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 (<a href="https://fusionio.com/" rel="nofollow">https://fusionio.com/</a>), a company building PCI-E SSDs, bypassing the SATA bus.
all he means behind the sensationalistic crap is that the sata controller is not actually needed, its there for compatibility.<p>"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.<p>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.<p>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.
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.
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.<p>the "nameless writes" idea is OK - a FS person would just call it even lazier allocation, not anything really different.
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.
The title is odd. Should be "Why SATA is now obsolete."<p>The article is of course correct, and some manufacturers are already offering SSD-like storage which is connected like a stick of RAM.<p>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.