So there are bugs in drive firmware. How about security bugs? Should we expect quality drives to have had a security audit?
SSDs: A gift and a curse
11–20 of 99 posts
Re: SSDs: A gift and a curse
#12Of 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…
And, contrary to a fly-by-night SSD manufacturer that's here today and gone tomorrow they have a reputation to protect and they suffer big time if a batch of faulty drives hits the market. See 'deathstar' and other re-runs of that concept. So they work very hard to make sure that doesn't happen to them.
Re: SSDs: A gift and a curse
#13I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.
Having the flash translation layer on the drive itself is the only practical way for the drive to be usable by multiple operating systems. Almost everyone who uses a SSD wants it to be accessible to at least two operating systems (UEFI, and whatever OS resides on the SSD). Doing the FTL on the host system would basically relegate the SSD to being just a cache device.
We have these things called standards which allow nice things like interoperability. Besides, you do not need the entire drive to be accessible from UEFI, it is enough that you can load a small bootloader which contains the drivers to handle the disk. Thirdly, UEFI has extensible right in the name, shouldn't be too hard for OSes to throw a disk driver blob into UEFI.
Re: SSDs: A gift and a curse
#14Of 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…
Oh there used to be a lot of HDD mfgr in perhaps 1985, all new products like this have an explosion of competitors, then they all get bought out or otherwise exit the market.
There used to be something like one hundred car manufacturers in the USA, around a century ago!
Another way to look at oligopolies is they no longer need to compete on quality or specs if they slack in unison, and the collapse and commodification of their product means they'll get nickel and dimed to death so I wouldn't expect perfection from them, they find ways to screw up. You can't "wish" or "push" commodity status on a market if mother nature and the economy in general prevent it from happening, forcing commodity style management onto a non-commodity product/market just makes a mess.
Re: SSDs: A gift and a curse
#15I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.
The user experience of win-modems, win-printers, and win-scanners was absolutely horrific so you really need to click edit and add the sarcasm tag.
Re: SSDs: A gift and a curse
#16I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.
This is a bad idea for a lot of reasons. A well designed system has components that just work and have standardized interfaces. What you're suggesting is that each device should be totally unusable unless the machine has the specific software running that knows how to use it. That's poor design.
Re: SSDs: A gift and a curse
#17So there are bugs in drive firmware. How about security bugs? Should we expect quality drives to have had a security audit?
Yes, firmwares have security bugs too: http://spritesmods.com/?art=hddhack
Re: SSDs: A gift and a curse
#18I 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.
Re: SSDs: A gift and a curse
#19The new flash DIMMs (which thus bypass PCIe bridges and ATA layer, since they plug directly into the memory controller) are really interesting. Not a commodity yet, but seems like a case where simpler -> better -> cheaper.
Re: SSDs: A gift and a curse
#20Of 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).