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

71–80 of 99 posts

Re: SSDs: A gift and a curse

#71

Post by GeorgeBeech »

deelowe wrote: post #69
GeorgeBeech wrote: post #68

Earlier quoted context omitted.

Not necessarily. We've been running Intel SSDs in productions at Stack Exchange for 4+ years, and just recently had our first 2.5" drive die. That said, most of the drives in this article are consumer drives. The problem with consumer drives is that they don't have capacitors. And since your writes are cached by the drive before they go to the NAND, if you lose power all of your drives will be corrupted in the exact…

Interesting. Do you have more info on what you mean by "Not necessarily?" From what I've seen during reliability studies on SSDs, they have a fairly tight failure curve. This is very dissimilar from hard disks where there's much more variance from drive to drive. I'm genuinely interested.

Nothing that would pass deep scrutiny. Just our experience running SSDs in almost every server at Stack. We've only had one mass failure of drives. That was when 5/8 Samsung drives died around the same time in our packet capture box. The remaining 3 are still alive, although we don't really use them.

We have only had two Intel drives die on us. I'm interested (well academically, not professionally) if they will die at the same time or keep dropping off one at a time.

We tend to retire the machines or the drives in them before they fail.

Re: SSDs: A gift and a curse

#72

Post by wtallis »

zanny wrote: post #51
ebbv wrote: post #16

Earlier quoted context omitted.

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 t…

Any such interface for SSDs would need to be able to work with a dozen different kinds of flash, a few sizes for each, a wide range of quantities of flash chips, all while exposing the performance and endurance characteristics of the flash and the topology of its connection to the host bus so that the software FTL can properly tune itself.

You're asking for a hardware interface of unprecedented complexity and cross-platform vendor neutral drivers of comparable complexity to 3d graphics drivers, all for the sake of letting SSDs have "dumb" controllers for a generation or two before the technology changes enough that the controllers need to start translating things again.

Re: SSDs: A gift and a curse

#74

Post by abecedarius »

cmdrfred wrote: post #55
abecedarius wrote: post #11

So there are bugs in drive firmware. How about security bugs? Should we expect quality drives to have had a security audit?

If you are doing your security at the hard drive layer, haven't you already lost?

So another reason for whole-disk encryption is to defend against your own drive firmware? I guess that may make sense nowadays, though it hadn't occurred to me.

Re: SSDs: A gift and a curse

#75

Post by Klinky »

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…

From personal experience I would trust neither to be infallible. I remember the IBM Deathstar drives, my Maxtor drives repeatedly dying along with their RMA replacements & the issues Seagate seems to have with 1.5TB & 3TB drives. When was the last time you had an SSD die from a dead motor or crashed heads?

Do you have intimate knowledge of the firmware writing process for hard drive manufacturing? Do you think knobs aren't twisted and codebases aren't rewritten to take into account the changes required for the latest in magnetic storage? Geometry calculations for perpendicular and shingled media is less complicated than a flash translation layer? Also just because something is old and hasn't broken yet, doesn't mean it's well written, bug free or will work in the future. This isn't to say that hard drives are reliable, as they're notoriously the least reliable thing in your computer.

Re: SSDs: A gift and a curse

#76

Post by dragontamer »

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…

50%+ failure rate on 3TB Seagates from Backblaze studies.

Something _horrible_ happened on the 3TB Seagate batch. 4TB and 2TB are reasonable... but 3TB... wtf happened?

Re: SSDs: A gift and a curse

#77

Post by userbinator »

rosser wrote: post #31
Rafert wrote: post #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.

Turns out, the Crucial drives' "power loss protection" doesn't actually preserve data "in-flight" at the moment of power loss. It just prevents data "at rest" from being corrupted. This appears to apply to all the consumer-grade Crucial drives. See [1], money quote: "In the MX100 review, I was still under the impression that there was full power-loss protection in the drive, but my impression was wrong. The client-le…

That is true of ordinary HDDs too. Until data is written to the flash or platter itself, it hasn't been actually written.

People don't expect files they haven't saved to be written and magically come back later if the power goes out, but they do expect that their drives will power back up with all the data that was last written intact.

Re: SSDs: A gift and a curse

#79

Post by yuhong »

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…

I think StorageReviews.com has an article on exactly this.

Re: SSDs: A gift and a curse

#80

Post by kabdib »

wtallis wrote: post #8
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.

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.

Yup. I looked at this while doing design work for a certain highly visible gaming product. You want the responsibility for block leveling and transactional goop close to the device, where the firmware can know stuff about device geometry and other nasty bits that affect reliability.

Putting that stuff in the OS puts you back to, oh, the same wicked stuff that people had to deal with for MFM hard drives (remember cylinder, head and sector counts? Only probably ten times more complicated).

A block level abstraction is fine, as long as the abstraction can make some transactional guarantees.

Post reply on HN