Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSDs: A gift and a curse

laur.ie

Post reply on HN
Print view View original

51–60 of 99 posts

Re: SSDs: A gift and a curse

#51

Post by zanny »

ebbv wrote: post #16
justinsb wrote: 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.

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.

Thats how... pretty much every peripheral in existance works. You need webcam drivers. Video card drivers. Sound card drivers. USB drivers, at the least for generic HID devices. Nothing stops there from being common standard generic SSD drivers, where vendors could publish their own if they had an optimization.

Right now the SATA interface prevents anything like that from happening, and the market has already moved to these proprietary broken controllers with braindead GL-class protocols to access them. (SATA, NVMe)

Re: SSDs: A gift and a curse

#53

Post by [deleted] »

zokier wrote: post #13
wtallis wrote: post #8

Earlier quoted context omitted.

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.

[deleted]

Re: SSDs: A gift and a curse

#54

Post by theatrus2 »

zanny wrote: post #50
mrb wrote: 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…

Sounds almost like having free software SSD firmware would be a nice thing. I just love how I have microcontrollers on all my persistent storage devices now that operate as a black box made by incompetent or possibly malicious developers.

You've always had this.

Re: SSDs: A gift and a curse

#57

Post by wyldfire »

wtallis wrote: post #42
whyoh wrote: post #39

Earlier quoted context omitted.

For example, the Intel 520 and 530 series have known issues. Besides the lower performance after some amount of writes, they also tend to randomly "disappear" from the system, which is much worse. Google it, it should be easy to find many related topics. I don't know if this only affects the SATA SSDs or not, but it happens a lot. (BTW, the random disappearing also affects some other SSDs from other brands.)

The Intel SSD 520 and 530 use SandForce controllers, so Intel started with a big mess and spent months trying to clean it up before shipping the drives. Clearly they missed a few bugs, and they couldn't work around every mistake and design limitation in the controller's hardware. Intel's in-house designs have an extremely good track record. I'm only aware of two major bugs.

We saw some performance issues with Intel's DC S3500 firmware. But they were able to fix them without too much hassle.

Re: SSDs: A gift and a curse

#58

Post by [deleted] »

zanny wrote: post #50
mrb wrote: 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…

Sounds almost like having free software SSD firmware would be a nice thing. I just love how I have microcontrollers on all my persistent storage devices now that operate as a black box made by incompetent or possibly malicious developers.

[deleted]

Re: SSDs: A gift and a curse

#59

Post by pja »

drzaiusapelord wrote: post #38
zokier wrote: post #25

Earlier quoted context omitted.

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

Ignoring that, Intel is rock solid. The larger issue isn't incompetents making SSDs, but SSDs being sold soley on performance. Intel has always been a step or two behind the performance game but manages to deliver some really reliable SSD's. I have yet to see a consumer Intel fail, which is incredible as that kind of reliability, outside of the super expensive PCIe cards is unheard of. I think we're a few more years…

I managed to brick an Intel 320 last week. Going to see if they’ll replace it under warranty - those devices were upgraded to a 5 years so it should still be covered.

(Apparently the drive really didn’t like being issued with an 'hdparm --security-set-pass X /dev/sdb' command. I was intending to do a secure wipe, for which the password setting is a pre-requisite, but the drive never came back from setting the password. After that it just returned junk data to any command, including 'hdparm -I /dev/sdb' & failed the power-on BIOS SMART test.)

Re: SSDs: A gift and a curse

#60

Post by bbulkow »

AYBABTME wrote: post #18
justinsb wrote: 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.

FusionIO cards run with FTL maintenance on the main CPU. Run a workload and you'll see the driver spinning in a way that isn't accounted for by your operations. It's not pretty - at high workloads, the network interrupt traffic starts interfering with all the bus traffic to the cards. A controller can be designed to run exactly at the speed of the chips, no more no less, leaving the CPU doing what it does best.

That being said, if you build your system correctly, there is not any extra CPU load created by maintaining the FTL at app level. The main problem is the lack of an API for wear detection. I have discussed this with senior chip designers at the major manufacturers, and they are all loath to nail down to one api, as they believe how wear is specified will have to change over time. That's a broad brush - some manufacturers are more open to these discussions than others.

I'm still working on them.

Post reply on HN