Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The point is there, though: hardware has more room to improve than software does, when it comes to IO-heavy tasks.


Err... Firmware has a history of being closed, buggy and quickly non-supported by the manufacturer. Block level abstraction exposed to the client is as brain-dead as it gets - and it is a good thing. Just imagine that your SSD had an S3-type interface for five years. And you only could use the tools that Amazon released five years ago. No updated versions. No bug fixes. And no "backend changes" to workaround bugs/etc and that was your only copy of the data.


We'd have hacks to support all of our OS level concepts like writable, readable, listable, executable, hidden, system, archive. How would someone implement tail, what about keeping something open for writing? I'm not sure any of this stuff is thought through except by OS writers. If we suddenly put this task to device manufacturers, would tail suddenly never work again? And if that doesn't work, what kind of monstrosity will happen if we simply attempt to start windows or linux on it?


And even though our OSes have bugs, at least we can reasonably debug and patch them. The same cannot be said of completely proprietary and invisible firmware.


Uh, alot of this is in firmware on the controllers of the SSDs. And often it's buggy as fuck to the point that Linux has blacklists hardcoded to deal with crappy firmware in SSDs.


I confess I'm not sure why people are talking about bugs now. I was talking about how hardware can access higher levels of performance and efficiently guarantee more things (eg. early persistence guarantees) than software can.


If the firmware has severe bugs (which is incredibly common with all firmware) and is hard to debug and patch, the performance is irrelevant. Not to mention that there are many examples of existing firmware bugs where the performance of "simple" hard drives tanked -- adding more code to already-buggy firmware that has a history of performance problems is unlikely to improve performance (let alone reliability).


This is a rather different claim to saying there wouldn't be a benefit. I'm not saying filesystem accelerator SSDs would necessarily be in sum a good thing, just that in principle it seems like the kind of thing that should perform better than today's abstractions.


Because the hardware is implemented with software.


You are rather missing the argument. If KV SSDs are much faster than doing the same with a software DB on top of a block abstraction, is that not proof that these are inequivalent? GPUs run software too, but that doesn't mean it's in anyone's best interests to run that on the CPU—not all software is the same, precisely because the hardware is different.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: