Live data from Hacker News

When Solid State Drives Are Not That Solid

blog.algolia.com

101–110 of 123 posts

Re: When Solid State Drives Are Not That Solid

#101
post #40
post #38

Earlier quoted context omitted.

There is no cloud - just other people's computers. Many use-cases just require the job to be done on your computers due to security and privacy reasons. Yes, Amazon's and Google's services are in some ways less secure than your own computer, because they are hosted by companies which are subject to a government that doesn't value privacy, not even of it's own citizens. That means said government can, just to give a c…

Thinking about individual computers will lead you astray. There are, rather, sets of machines (from single boxes to entire data-centers) that are managed by a given sysadmin staff. The more machines they manage, the more likely it is that problems will have institutionalized and operationalized solutions. A cloud is just a sysadmin staff with a Sufficiently Large Deployment to have ironed out all the kinks in their h…

Or the more likely they'll not do advanced stuff in order to increase profit, as long as there is a microscopic delta better than running it yourself for most customers most of the time on average. The microscopic delta may not be measurable or noticeable by the end users of course.

Assuming their business model isn't assuming an infinite supply of future customers so in the short term as long as revenue per customer exceeds cost of sales per customer we're all good, etc. Support costs that exceed average cost of sales must be beaten down/ignored, otherwise its cheaper to let them go and have sales "earn" a replacement customer.

Finally their sysadmins work for them to meet their corporate objectives of various meaningless metrics which have no necessity of aligning in any way with your own corporate objectives.

Re: When Solid State Drives Are Not That Solid

#102
post #57

Earlier quoted context omitted.

Or Btrfs on Linux.

In theory, yes. Unfortunately, every time my Btrfs filesystems have encountered a hardware glitch, it has happily trashed the filesystem beyond recovery (including both drives in a RAID1 mirror, one of which was perfectly OK). I use ZFS now, and while some features are compatable with Btrfs, the implementation quality, documentation, and feature completeness, and tool quality set it well above where Btrfs is at.

I fully second that: I'm using btrfs for / and ZFS for /srv. So many rashed filesystems beyond recovery on btrfs, so many joy, stability and easy tools for ZFS.

I'm really about to consider to migrate / to ZFS now.

Re: When Solid State Drives Are Not That Solid

#103

"Samsung SSD 850 PRO 512GB recently blacklisted as 850 Pro and later in 8-series blacklist" That's what I have in my home computer, with ArchLinux. Do you think this problem only is something particular in the servers of the author of that article, or should this be interpreted as: linux + samsung 850 = you will lose your data? Thanks...

Unless you run the latest kernel, I would disable TRIM.

Re: When Solid State Drives Are Not That Solid

#104

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.

The drives we have detected the issue had still un-queued TRIM. I have reached to one of the kernel I/O developers for help and he confirmed that it is not related.

But isn't the blacklist you link to in the article specifically for queued TRIM? E.g. https://github.com/torvalds/linux/commit/9a9324d. SO either that blacklist has nothing to do with this issue (in which case it probably shouldn't be linked from the article), or it does, and we're talking about issues with queued TRIM.

Re: When Solid State Drives Are Not That Solid

#105

Earlier quoted context omitted.

The drives we have detected the issue had still un-queued TRIM. I have reached to one of the kernel I/O developers for help and he confirmed that it is not related.

But isn't the blacklist you link to in the article specifically for queued TRIM? E.g. https://github.com/torvalds/linux/commit/9a9324d . SO either that blacklist has nothing to do with this issue (in which case it probably shouldn't be linked from the article), or it does, and we're talking about issues with queued TRIM.

The article very clearly states that the issue had nothing to do with queued or unqueued TRIM:

Our affected drives did not match any pattern so they were implicitly allowed full operation.

See the list:

  SAMSUNG MZ7WD480HCGM-00003
  SAMSUNG MZ7GE480HMHP-00003
  SAMSUNG MZ7GE240HMGR-00003

Re: When Solid State Drives Are Not That Solid

#106
Been there, done that. :|

Sometime around the end of 2013 I started getting frequently lost data and corrupted filesystems upon reboot. After much search and about 4-6 months into the issue, I found out that the culprit were the queued TRIM commands issued by the linux kernel to my Crucial M500 mSATA disk. The Linux kernel already had a quirks list with many drives, including some of the M500 variants, just not mine.

I added my model, compiled the kernel and the nightmare ended. I proceeded to submit a bug report and a patch. The patch got accepted (yay!) and the bug report turned to be very useful for other people with the same problem but different disk as I included the dmesg output that was specific to the issue. This meant that they could now google the errors and get a helpful result.

Such is the nature of free software; you are allowed to fix your computer yourself. :)

Re: When Solid State Drives Are Not That Solid

#107
Undoubtedly the same issue happened to me on an 500GB 840 EVO with NTFS.

SSD zeroed out a part of the disk during runtime, as I watched this happen music was playing from this drive. It was mounted from Ubuntu MATE 15.04 and playing a music library through Audacious. Suddenly music glitched and IO errors began appearing. Rebooted to a DISK READ ERROR (MBR was on the EVO). Ran chkdsk from USB and it showed a ridiculous amount of orphaned files for ca. 1h. Once finished the most frequently accessed files had disappeared. Download folder, Documents folder, some system files. Of course, some of the files could've been recovered had I not ran chkdsk off the bat, bot nonetheless it's an approximate measure of failure impact.

I began being suspicious of 840 EVO when sorting old files by date became fantastically slow. If you have a feeling this has happened to you recently - buckle up for a shitstorm.

TL;DR Avoid 840 EVO.

Re: When Solid State Drives Are Not That Solid

#109
post #83

Strange, Samsung 840/850 evo/pro are considered [1][2] among the best consumer SSDs. The issues article mentions do not exist on Windows, the SSDs are very reliable there. I suspect it's not only Samsung fault. Are we sure Linux handling of TRIM operations is absolutely correct? [1] http://techreport.com/review/27062/the-ssd-endurance-experim... [2] http://www.anandtech.com/show/8216/samsung-ssd-850-pro-128gb...

Personally, I find Samsung has a "it boots? Fine then ship," mentality to pretty much all things. Their buggy phones, buggy SSD's, buggy TV's, etc. I wouldn't recommend them, even though they do well on SSD speed tests (which are often gamed by on-board ram caching).

The 840 Pro exceeded 2.4PB of writes before failing in Anandtech's tests over 18 months: http://techreport.com/review/27909/the-ssd-endurance-experim...

Even if Samsung has some systemic problems, it's more subtle than just schlocky marketing, or targeted benchmarking.

Post reply on HN