Live data from Hacker News

SSDs: A gift and a curse

laur.ie

21–30 of 99 posts

Re: SSDs: A gift and a curse

#21
post #9

All these drives were on hardware RAID cards it seems, is it feasible to do without them?

Preferable, I'd say. The last thing you want between your OS and your disks is a buggy unknowable black box you can only talk to with some crappy binary blob management tools.

Re: SSDs: A gift and a curse

#22
post #3
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Unfortunately that day isn't going to happen. In fact the opposite is happening -- interesting spinning rust technology like Shingled Magnetic Recording (SMR) drives are getting more complex translation layers.

I wouldn't say that it's never going to happen based on current trends.

This kind of thing tends to be quasi-cyclic.

At one time, desktop computers had separate FPUs. Over time, those got integrated onto the main CPU, but then the trend switched back, with heavy calculations moving off-CPU to the GPU.

The mainframe->desktop->cloud story is similar.

I say "quasi"-cyclic because (e.g.) cloud isn't really the same as mainframe, but the transition back and forth between centralized and decentralized is still striking nonetheless.

Re: SSDs: A gift and a curse

#23
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Wouldn't that make performance a lot worse, for both CPU and disks? Offloading the job to something closer to the flash chips and fully dedicated to servicing them sounds like a better (and the current) path. Same for high speed network links.

This is appropriate: http://www.catb.org/jargon/html/W/wheel-of-reincarnation.htm...

Re: SSDs: A gift and a curse

#24
post #20
post #10

Of course SSD firmware is buggy. You know why? Because any half-decent electrical and computer engineering team can slap a NAND flash controller and some flash chips on a PCB, take the controller's manufacturer's reference firmware implementation, tweak the dozens of knobs provided by the reference implementation (ignore FLUSH commands, change the amount of reserved sectors, disable this, enable that, etc), change th…

That is a nice theory, except for the fact that firmware bugs have hit big players equally badly, if not even worse. Intel and Samsung come easily to mind, and Sandforce was notorious for not getting their own firmware to work (for their own controllers).

Since when has Intel been hit equally?

Re: SSDs: A gift and a curse

#25
post #20

Earlier quoted context omitted.

That is a nice theory, except for the fact that firmware bugs have hit big players equally badly, if not even worse. Intel and Samsung come easily to mind, and Sandforce was notorious for not getting their own firmware to work (for their own controllers).

Since when has Intel been hit equally?

The "8MB bug" (https://communities.intel.com/thread/24205) was the most notorious, but I remember also some bricked Intel SSDs too.

Re: SSDs: A gift and a curse

#26
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Wouldn't that make performance a lot worse, for both CPU and disks? Offloading the job to something closer to the flash chips and fully dedicated to servicing them sounds like a better (and the current) path. Same for high speed network links.

Flash translation layers don't really need to be offloaded for the sake of performance. You need some kind of controller to multiplex access to a dozen or more flash chips from a narrow PCIe link, so you might as well throw in an ARM core to do the translation and wear leveling and garbage collection, and then you can stick a few supercaps in the drive too and have a robust hardware platform.

Re: SSDs: A gift and a curse

#27
post #23

Earlier quoted context omitted.

Wouldn't that make performance a lot worse, for both CPU and disks? Offloading the job to something closer to the flash chips and fully dedicated to servicing them sounds like a better (and the current) path. Same for high speed network links.

This is appropriate: http://www.catb.org/jargon/html/W/wheel-of-reincarnation.htm...

Always have that in the back of my mind =]. However I don't think that's the current trend right now. Except where special hardware is integrated to the chip, but the work isn't left to the CPU itself.

I'm not so versed in the area so I'm just blind guessing here.

Re: SSDs: A gift and a curse

#28
post #20
post #10

Of course SSD firmware is buggy. You know why? Because any half-decent electrical and computer engineering team can slap a NAND flash controller and some flash chips on a PCB, take the controller's manufacturer's reference firmware implementation, tweak the dozens of knobs provided by the reference implementation (ignore FLUSH commands, change the amount of reserved sectors, disable this, enable that, etc), change th…

That is a nice theory, except for the fact that firmware bugs have hit big players equally badly, if not even worse. Intel and Samsung come easily to mind, and Sandforce was notorious for not getting their own firmware to work (for their own controllers).

My theory predicts that even big players will have bugs (if only due to my last point: complexity). But I insist that small players will tend to have even more bugs.

Re: SSDs: A gift and a curse

#29
I am surprised they haven't mentioned Crucial SSDs. With cheap drivers like the MX100 having features as power loss protection and Opal 2.0 support, I preferred these over the slightly faster Samsung products at the time.

Re: SSDs: A gift and a curse

#30
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Wouldn't that make performance a lot worse, for both CPU and disks? Offloading the job to something closer to the flash chips and fully dedicated to servicing them sounds like a better (and the current) path. Same for high speed network links.

The FTL runs much faster on a 3GHz Xeon core than on a 150MHz ARM core. Of course, the cost and power consumption is also much higher.
Post reply on HN