
OpenSSD – Open firmware for SSDs - uaygsfdbzf
http://www.openssd-project.org/
======
pedrocr
Is there any reason we'd actually want this firmware at all vs just using a
flash filesystem running on the host CPU? Is there really any significant
performance advantage to be had?

I really wish normal SSDs just implemented a passthrough mode to the real
flash with enough metadata about blocks that the OS can just deal with it
directly. Having to implement filesystems on top of these abstractions just
seems wrong. We're setting us up to later find out that we need to join the
two layers like ZFS did with RAID.

~~~
userbinator
Performance advantage, maybe not, but in terms of reliability (which I think
for storage devices is _far more important_ than absolute performance) there's
definite advantages to having the SSD have its own processor; an SSD is
running a realtime control firmware so it can react quickly to events like
sudden power loss and act appropriately to flush pending writes and update the
BMTs before the power completely dies, whereas the host CPU would basically
have no chance at that due to the fact that it's probably doing something else
at the time and the latency of communicating to the SSD.

~~~
pedrocr
I'm not suggesting the SSD shouldn't have it's own CPU, I'm just suggesting it
be dumbed down and not run complex and potentially buggy wear leveling
algorithms pushing those up the stack.

~~~
al2o3cr
So your suggestion for _reducing_ the bugginess of wear-leveling algorithms is
to remove them from a dedicated, known-at-compile-time dedicated hardware
environment and instead run them on whatever mystery-meat general-purpose
stuff the user has?

Can I get a hit off whatever you've got over there? ;)

~~~
jrockway
His suggestion is to not trust random hacked-together-for-a-last-second-
release vendor code, and instead use a continuously-developed firmware
developed in the open with tests and a broad userbase.

The first rule of hardware is that hardware companies can't write software.

------
baruch
A while ago I tried to buy one to play with it, they quoted me $3000 and it is
well above my personal budget for playing with it. It is only attainable by a
university or a company not mere persons.

I really wish I could get my hands on an SSD that I could program the firmware
for to play with things. It would require more than one sample or at least the
ability to replace the flash modules since it's likely I'll burn through them
with the initial failed attempts. The OpenSSD I looked at did have replaceable
flash modules.

~~~
jacquesm
It's a low volume PCIex card, those aren't cheap to make. There are some
cheaper alternatives, maybe you could adapt this firmware to run on one of the
cheaper cards.

~~~
baruch
If there was an option to take an existing high volume product and get the
tools and interface documentation to create and modify the firmware for I'd
jump on that bandwagon as well. So far I didn't find anything like that.

~~~
userbinator
There's plenty of existing SSDs using the Indilinx Barefoot:

[http://en.wikipedia.org/wiki/Indilinx](http://en.wikipedia.org/wiki/Indilinx)

You probably need to do a bit of reverse-engineering, but the project has
released the firmware source code and controller programming information, so
go for it!

------
jacquesm
Another 5 to 10 years and flash will be memory mapped and on the mother board.
It's simple economics, fewer parts = lower costs. Maybe it'll even go on-die
at some point since the footprint of flash is a lot smaller than the footprint
of RAM.

~~~
rasz_pl
no it wont. Nand flash is

-full of bad cells straight from factory -block erasable

you cant simply plonk it on the board, memory map and expect access like ram.

~~~
jacquesm
That just requires _one_ level of indirection, which is easily done through a
lut of some kind, either in hardware or software.

------
userbinator
There's some good technical information here:

[http://www.openssd-
project.org/wiki/Jasmine_Technical_Resour...](http://www.openssd-
project.org/wiki/Jasmine_Technical_Resources)

What pleases me most about this is that it's probably the first time this
level of documentation has been released for a commercially-used SSD
controller; in fact the biggest thing I see coming out of this is not the
hardware, but the possible development of alternative open-source firmware for
existing commercial SSDs with the same controller. The majority of them are
going to be virtually identical to this reference design. The schematics are
theoretically enough for anyone to make their own. That's why, for their other
platform based on an FPGA, I don't think it's as interesting.

Unfortunately this comes a bit late to save all those bricked OCZ Vertexes (or
would that be Vertices) out there, but maybe similarly nonfunctional/damaged
drives with the same controller could make good test platforms for this
firmware...

Open SSD firmware would be another way to prevent maliciousness; see
[http://spritesmods.com/?art=hddhack](http://spritesmods.com/?art=hddhack) for
example.

~~~
Someone
Prevent maliciousness? I foresee root kits that hide themselves. For example,
your SSD could magically develop the equivalent of bad blocks after the OS has
loaded the boot sector (first read of block X, if done within Y seconds of
power on, returns root kit's boot sector. Any other call returns the
uninfected version)

Your anti-malware firmware would have to disable firmware updates to prevent
that, moving it into the OCZ Vertex category.

~~~
userbinator
Government agencies like the NSA already know how to do this.

The usual firmware update happens over the regular SATA interface, and is also
controlled by the firmware itself; however, there is a "factory mode" that
requires physical access and is always available - it's how the initial
firmware is loaded - so even if you use firmware that doesn't allow updating
via regular means, you can still update it if you really need to. The factory
mode might be via JTAG, or require a specific voltage on a pin upon reset to
enable, and that's something that no malware can silently do...

I wonder if OCZ might've not suffered the same fate had they open-sourced
their SSD firmware after they bought Indilinx, since one of the biggest
problems they had was firmware bugs.

~~~
rasz_pl
OCZ skimped on simple things like capacitor to sustain last write on power
loss.

------
rasz_pl
Wiki mentions OCZ's Vertex/Vertex Turbo/Agility/Solid drives. Does this mean I
can buy one of the bricked OCZ drives and start playing with firmware using
openssd codebase?

Lack of reasonably priced hardware platforms limits this project to academia.

~~~
danielvinson
Not all of the Vertex 2/Agility 2 drives which were bricked were due to
firmware issues. Around 25% of drives which failed were due to NAND failures
and the lost firmware or corrupted firmware fixes often only fixed about
50%-75% of the drives which they were applied to.

Edit: FYI these numbers are purposely not very accurate.

------
ck2
What's also interesting is the new F2FS by samsung on many linux distributions
now (open source).

Shows higher performance on SSD than ext4 and virtually all other file
systems.

------
sanxiyn
I am so happy to see a project from South Korea hitting the HN front page.

