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

41–50 of 123 posts

Re: When Solid State Drives Are Not That Solid

#41

Post by simoncion »

madez wrote: post #32
caf wrote: post #31

Earlier quoted context omitted.

Is the loss of reputation really worth less than the value of the externalised testing?

That remains to be seen. I really hope not. With Samsungs finished-forms walling the company already tells Linux users to not expect any support, at all. So, that is consisting with the testbed-theory.

> With Samsungs finished-forms walling the company already tells Linux users to not expect any support, at all.

I'm sorry. I'm too dumb to parse this. :( Would you kindly rephrase it?

Thanks much. :)

Re: When Solid State Drives Are Not That Solid

#42

Post by will_hughes »

jlebar wrote: post #36

To me, this sort of thing brings home the value of not running your own machines. Sure, Amazon's/Google's clouds have quirks, but it's far less likely that you're going to have to debug faulty hardware in this way. It sounds like a team of more than one person worked on this at least part-time for weeks -- how much is that worth? It's not just the cost of hiring extra people to do the work; often small companies simp…

If something similar happens to you on "cloud" infrastructure, you're very limited in what you can do to diagnose or work-around the problem.

At a place I used to work at we had a reasonably large cluster of Windows boxes on Amazon. Randomly, Windows machines on Amazon would suddenly stop accepting new TCP connections.

This means that machines would be running fine, and then half your cluster starts dropping offline. At the time when this happened to us, there were no other reports we could find of this happening.

Turns out, it's some bug in the Xen Virtual NIC driver that wasn't running the offloaded TCP cleanup, and so eventually the system couldn't accept any new connections. Once we figured out was happening we could pre-emptively reboot boxes, but that was a problem for us for about 6 months iirc.

There's probably dozens of these bugs affecting someone on these cloud platforms at any one time. But because you have no access to the hardware, you don't even have the option of saying "Screw it, lets just get different hardware". You're at the mercy of your cloud provider.

Re: When Solid State Drives Are Not That Solid

#43

Post by _yosefk »

digi_owl wrote: post #24
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.

The thing is, almost all hardware accessed through drivers has tons of bugs, at least it's nowhere near as close to "bug-free" as are things like CPUs or DRAMs which cannot hide their bugs behind drivers. The thing that one can hope to work reasonably is a piece of hardware plus an accompanying driver which knows to hide that hardware's issues.

So another way of putting what you said would be "on Linux there's no working driver for that piece of hardware, unlike on Windows where the 'proprietor' went to the trouble of supplying such a driver."

Re: When Solid State Drives Are Not That Solid

#45

Post by adamsurak »

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 this case the TRIM command was un-queued, which makes it worse.

Re: When Solid State Drives Are Not That Solid

#46

Post by adamsurak »

jlebar wrote: post #36

To me, this sort of thing brings home the value of not running your own machines. Sure, Amazon's/Google's clouds have quirks, but it's far less likely that you're going to have to debug faulty hardware in this way. It sounds like a team of more than one person worked on this at least part-time for weeks -- how much is that worth? It's not just the cost of hiring extra people to do the work; often small companies simp…

With our architecture, HW requirements, the price of HW and the price of the cloud VMs, even working on this for a week or two saves us significant amount of money both short-term and long-term. The side effect is that we now have tools to recover servers way faster and allows us to do things we have not thought about before.

Re: When Solid State Drives Are Not That Solid

#47

Post by adamsurak »

teraflop wrote: post #22

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.

Re: When Solid State Drives Are Not That Solid

#48

Post by mrmondo »

I've worked on some interesting SSD deployments / experiments a lot over the past 12 months. Quite honestly - I wouldn't go anywhere near Samsung products regardless of their 'PRO' labelling or otherwise.

We have had great success with both Sandisk Extreme Pro SATA and Intel DC NVMe series drives, we've also recently deployed a number of Crucial 'Micron' M600 1TB SATA drives that are performing very well and so far haven't given us any issues.

Re: When Solid State Drives Are Not That Solid

#49

Post by adamsurak »

madez wrote: post #25

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.

In this case it was un-queued TRIM (I forgot to mention it in the blogpost). We have reached to Samsung and although it looked good at the beginning now they are silent for more than a month without any progress.

Re: When Solid State Drives Are Not That Solid

#50

Post by jjawssd »

_yosefk wrote: post #43
digi_owl wrote: post #24

Earlier quoted context omitted.

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

The thing is, almost all hardware accessed through drivers has tons of bugs, at least it's nowhere near as close to "bug-free" as are things like CPUs or DRAMs which cannot hide their bugs behind drivers. The thing that one can hope to work reasonably is a piece of hardware plus an accompanying driver which knows to hide that hardware's issues. So another way of putting what you said would be "on Linux there's no wor…

If you think CPUs do not come with a shit-ton of hardware bugs YOU ARE GRAVELY MISTAKEN.

Google up the Intel errata for the i7

The list goes on and on.

Post reply on HN