SSDs: A gift and a curse • Hacker News Board

Re: SSDs: A gift and a curse

#31

Post by rosser » Tue, Jun 02, 2015, 6:58 PM UTC

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-level implementation only guarantees that data-at-rest is protected, meaning that any in-flight data will be lost, including the user data in the DRAM buffer. In other words the M500, M550 and MX100 do not have power-loss protection -- what they have is circuitry that protects against corruption of existing data in the case of a power-loss."

[1] http://www.anandtech.com/show/8528/micron-m600-128gb-256gb-1...

Re: SSDs: A gift and a curse

#32

Post by yellowapple » Tue, Jun 02, 2015, 7:03 PM UTC

Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fails, you might as well kiss your data goodbye, since the replacement - 9 times out of 10 - won't be able to make sense of its predecessor's RAID setup).

Also, RAID6 is a bad idea, almost as bad as RAID5. There have been numerous studies and reports [0] indicating that both are very susceptible to subtle bit errors ("cosmic rays"), and this is made even worse when SSDs are involved. If you need absolute data integrity, RAID1 is your only option; if you need a balance between integrity, performance, and capacity, go with RAID10, which is still leaps-and-bounds better than RAID5/6.

[0]: http://www.miracleas.com/BAARF/Why_RAID5_is_bad_news.pdf

Re: SSDs: A gift and a curse

#33

Post by JoeAltmaier » Tue, Jun 02, 2015, 7:10 PM UTC

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…

Early SSD failures were all firmware bugs. As time goes on that has receeded into noise. Now SSD failure stats show sensible wear patterns.

Re: SSDs: A gift and a curse

#34

Post by JoeAltmaier » Tue, Jun 02, 2015, 7:12 PM UTC

yellowapple wrote: post #32

Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fail…

To expand: in my 20-year experience, no small-computer RAID 5/6 controller I have had experience with has ever saved any data, ever. All failures are hard and non-recoverable. Which begs the question: why use them at all? I mirror only.

Re: SSDs: A gift and a curse

#35

Post by MichaelGG » Tue, Jun 02, 2015, 7:23 PM UTC

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.

The power loss protection in Crucial drives is not what most people think it is. It's a guarantee that the drive won't become corrupted on power loss, not that data buffers will be committed. So it's still dangerous. The idea that the drive would lose existing data on power loss was very surprising to me in the first place, enough that I never suspected that's what Crucial meant by power loss protection.

Re: SSDs: A gift and a curse

#36

Post by bduerst » Tue, Jun 02, 2015, 7:48 PM UTC

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.

Doesn't that require partitioning the disk? That doesn't seem like an OOB solution.

Re: SSDs: A gift and a curse

#37

Post by rsync » Tue, Jun 02, 2015, 7:50 PM UTC

yellowapple wrote: post #32

Parts of this sound more like hardware RAID controller issues than SSD issues, which is why I typically avoid hardware RAID in production environments unless there's a specific reason for it. RAID controllers tend to be buggy pieces of shit, usually implementing some RAID method that's more-or-less proprietary and unique even between different RAID cards from the same vendor (meaning that if your RAID controller fail…

A modern filesystem, like ZFS, will protect against random bit errors.

Raid 5/6 are still not appropriate for todays large disk sizes, but raidz3 (three parity disks instead of one or two) is.

Re: SSDs: A gift and a curse

#38

Post by drzaiusapelord » Tue, Jun 02, 2015, 7:55 PM UTC

zokier wrote: post #25

scott_karana wrote: post #24

Earlier quoted context omitted.

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.

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 of shaking out this industry and leaving behind all the growing pains. No idea who will be left standing, but I suspect Intel will probably be around.

Re: SSDs: A gift and a curse

#39

Post by whyoh » Tue, Jun 02, 2015, 8:04 PM UTC

scott_karana wrote: post #24

zokier wrote: 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?

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.)

Re: SSDs: A gift and a curse

#40

Post by wtallis » Tue, Jun 02, 2015, 8:10 PM UTC

bduerst wrote: post #36

zokier wrote: post #13

Earlier quoted context omitted.

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.

Doesn't that require partitioning the disk? That doesn't seem like an OOB solution.

It's not the requirement to partition the drive that kills the idea. Setting aside the first small chunk of the drive for the firmware to read is how it's always been done. The problem is that this would require the partitioning to be done below the wear leveling layer, which reduces the effectiveness of the wear leveling slightly and means you can only change your bootloader settings a thousand times before the drive is dead.