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

When Solid State Drives Are Not That Solid

blog.algolia.com

Post reply on HN
Print view View original

21–30 of 123 posts

Re: When Solid State Drives Are Not That Solid

#21

Post by sandGorgon »

I have this running on my Ubuntu Thinkpad with A Samsung 840 Pro as a weekly cron job. should I turn it off ?

  #!/bin/sh
  # call fstrim-all to trim all mounted file systems which support it
  set -e
  
  # This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty
  # firmware may encounter data loss problems when running fstrim under high I/O
  # load (e. g.  https://launchpad.net/bugs/1259829). You can append the
  # --no-model-check option here to disable the vendor check and run fstrim on
  # all SSD drives.
  exec fstrim-all

Re: When Solid State Drives Are Not That Solid

#22

Post by teraflop »

Here's an Ubuntu bug tracker entry for what sounds like the same problem: https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/144900...

Linux 4.0.5 includes a patch that blacklists queued TRIM for the buggy drives. Windows and OS X apparently don't support queued TRIM at all, so they're unaffected.

Re: When Solid State Drives Are Not That Solid

#23

Post by xfalcox »

ploxiln wrote: post #20
kuschku wrote: post #16

Earlier quoted context omitted.

So, if I don’t update the firmware of my 840 EVO, I can continue using it with discard?

I'm not sure exactly when the first 840 EVO firmware which advertised queued trim support (along with SATA 3.1/3.2 support) was released, but I think that if you last updated firmware (or acquired the drive) before October 2014, you're safe. However, if you don't update your firmware, you'll suffer from significant performance degradation when reading old files: http://www.anandtech.com/show/9196/samsung-releases-sec…

The old file performance hit is VERY big, I can't overstate the need to upgrade.

Re: When Solid State Drives Are Not That Solid

#24

Post by digi_owl »

ploxiln wrote: post #3

Originally TRIM was an un-queued command; all writes had to be flushed, then TRIM executed, then writes could continue. This was bad for performance with automatic on-file-delete trim, so everyone wanted a trim command that could be put in the command queue along with writes. Many new drives have this. It turns out that Samsung 8XX SSDs advertise they support queued trim but it's buggy. The old TRIM command works fin…

In essence the Linux kernel put on display what is on Windows hidden by proprietary device drivers.

Re: When Solid State Drives Are Not That Solid

#25

Post by madez »

It feels like Samsung used the Linux community here as a free testbed.

Samsung knew that only Linux supported queued trim, so releasing it without proper testing is just externalizing the disproportionately increased cost of testing to the Linux community.

Re: When Solid State Drives Are Not That Solid

#26

Post by teraflop »

sandGorgon wrote: post #21

I have this running on my Ubuntu Thinkpad with A Samsung 840 Pro as a weekly cron job. should I turn it off ? #!/bin/sh # call fstrim-all to trim all mounted file systems which support it set -e # This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty # firmware may encounter data loss problems when running fstrim under high I/O # load (e. g. https://launchpad.net/bugs/1259829). You can append…

Probably, unless you're running a kernel that was released within the last couple of weeks and includes this patch: https://github.com/torvalds/linux/commit/9a9324d

Re: When Solid State Drives Are Not That Solid

#28

Post by cft »

Using SAS SSD drives on a server is a bad idea for many reasons. One should use PCIe cards, that sit directly on the PCIe bus, such as FusionIO or SanDisk. They have been tested and retested (e.g. by Facebook), without the unnecessarily added complexity of SAS/SATA protocols. The I/O performance is also about 20x.

Re: When Solid State Drives Are Not That Solid

#29

Post by feelix »

bbcbasic wrote: post #11

I have a Samsung SSD 850 PRO 512GB in my Windows PC. And I have TRIM enabled in Windows: > fsutil.exe behaviour query DisableDeleteNotify DisableDeleteNotify = 0 Should I be worried?

This issue is related to TRIM in the context of command queuing, not the relatively ancient straightforward TRIM which Windows supports.

Re: When Solid State Drives Are Not That Solid

#30

Post by Figs »

guns wrote: post #18
ploxiln wrote: post #9

Earlier quoted context omitted.

Do you have the "discard" mount option enabled? Do you have a cron job that runs the "fstrim" command? It's possible your systems are not running trim. Or maybe your ext4 filesystems have little activity and you haven't had enough corruption to notice yet :) Also, some Samsung 800 series drives only gained this bug in a recent firmware update (840 EVO specifically).

The 840 EVO joined the club with firmware EXT0DB6Q, which itself is a nasty little hack around a fundamental design problem with the tightly packed NAND cells. Linux 4.0.5 ships with the patch linked above, but for a while you had to roll with a kernel built from source. EDIT: The blatant file corruption issues only manifested after updating to firmware EXT0DB6Q.

Is there a list of firmware versions with release dates somewhere? I can't seem to find a changelog.
Post reply on HN