SSD [LWN.net]

SSD

Posted Oct 5, 2009 13:09 UTC (Mon) by i3839 (guest, #31386)
In reply to: SSD by dwmw2
Parent article: LinuxCon: Kernel roundtable covers more than just bloat

I agree with you, but I understand the other side too.

> But I see absolutely no reason why we should put up with the "hardware"
> actually doing that kind of thing for us, behind our back. And badly.

Three reasons:

- Interoperability without losing flexibility.
For a "dumb" block driver to work the translation table must be fixed.
And when running in legacy mode the drive will be very slow. There are
a heap of problems waiting when it gives write access too.
It's very hard to let people switch filesystems. They mostly use the
default one from their OS, or FAT. As long as disks are sold as units
and not as part of a system this will be true.

- Performance.
Having dedicated hardware doing everything is faster and uses less power.
Not talking about an ARM mc, but a custom asic. (Just compare Intel's
SSD idle/active power usage to others.)

- Fast development.
Currently the flash chip interface is standardized with ONFI and the
other end with SATA. All the interesting development happens in-between.
Because it's wedged between stable interfaces it can change a lot without
impacting anything else (except when it's done badly ;-).

So short term the situation is quite hopeless for direct hardware access.
The best hope is probably SSDs with free specifications and open source
firmware.

Long term I think we should get rid of the notion of a disk and go more
to a model resembling RAM. You could buy arrays of flash and plug them in,
instead of whole disks (they could look like "disks" to the user, but
that's another matter). This decouples the flash from the controller
and makes data recovery easier in case the controller dies.

What is needed is a flash specific interface which replaces SATA and
implements the features that all good flash file systems need: Things
like multi-chip support, ECC handling, background erases and scatter
gather DMA. Perhaps throw in enough support to implement RAID fast
in software, if it makes enough sense. Basically a standardized small,
simple and fast flash controller, preferably accessible via some kind of
host memory interface (PCIe on x86). Make sure to make it flexible enough
to handle things like MRAM/PRAM/FeRAM too.

Maybe AHCI is good enough after a few adaptations, but it can be probably
a lot better. Or perhaps some other interface from the embedded world fits
the description.

This will make embedding the controller on a SoC easier too, without the
need for special support in the OS. SATA is really redundant in such cases.

I'm pretty sure most flash controllers already have such chip, but don't
expose it. Instead they hide it behind an embedded microcontroller which
handles SATA and implements the FTL. They should standardize it and get
rid of the power hungry, complexity adding bloat.

I also think it's crucial to get optimal performance, flash gets faster
and faster. It seems pointless to get faster and faster SATA when PCIe
is already fast enough. It's also silly to fake SATA by just implementing
a AHCI controller with direct flash access. Keep SATA around for real
external storage, not something that doesn't take much space anyway.

People that look at SSDs and see them just as disks and don't think about
the future will think it's best if the hardware does as much as possible.
But if you forget the classic disk model and look at what's really going
on it seems obvious that the classic disk model isn't that simple anyway
and doesn't fit flash or how the hardware looks like and could be used.

(Log in to post comments)

SSD

Posted Oct 6, 2009 6:23 UTC (Tue) by dwmw2 (subscriber, #2063) [Link]

We should probably take this discussion elsewhere. Your input would be welcome on the MTD list, where I've started a thread about what we want the hardware to look like, if we could have it our way.

But just a brief response...

"- Interoperability without losing flexibility."

This is still possible with a more flexible hardware design — you just implement the translation layer inside your driver, for legacy systems. M-Systems were doing this years ago with the DiskOnChip. More recently, take a look at the Moorestown NAND flash driver. You can happily use FAT on top of those. But of course you do have the opportunity to do a whole lot better, too. And also you have the opportunity to fix the translation layer if/when it goes wrong. And to recover your data.

"- Performance"

But this isn't being done in hardware. It's being done in software, on an extra microcontroller.

Yes, we do need to look carefully at the interface we ask for, and make sure it can perform well. But there's no performance-based reason for the SSD model.

"- Fast development"

You jest, surely? We had TRIM support for FTL in Linux last year, developed in order to test the core TRIM code. When do we get it on "real hardware"? This year? Next?

Being "wedged between stable interfaces" isn't a boon, in this case. Because it's wedged under an inappropriate stable interface, we are severely hampered in what we can do with it.

"People that look at SSDs and see them just as disks and don't think about the future will think it's best if the hardware does as much as possible. But if you forget the classic disk model and look at what's really going on it seems obvious that the classic disk model isn't that simple anyway and doesn't fit flash or how the hardware looks like and could be used."

Agreed. I think it's OK for the hardware to do the same kind of thing that disk hardware does for us — ECC, and some block remapping to hide bad blocks. But that's all; we don't want it implementing a whole file system of its own just so it can pretend to be spinning rust. In particular, perpetuating the myth of 512-byte sectors is just silly.