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

111–120 of 123 posts

Re: When Solid State Drives Are Not That Solid

#111

Post by derefr »

vidarh wrote: post #74
derefr wrote: post #40

Earlier quoted context omitted.

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…

> A cloud is just a sysadmin staff with a Sufficiently Large Deployment to have ironed out all the kinks in their hardware. By that definition, I don't think there are any clouds.

True, by the literal definition. I continue to interpret "cloud" as "that mysterious part in the middle of the diagram which is a clean encapsulation of Somebody Else's Problem that never bothers you"; obviously, there are no true "clouds" (and there cannot be) by that definition.

But people can try, and they can get close; and one can say that something is a cloud to the degree that it manages to fulfill the "amorphous shape in your diagram you don't have to worry about" promise. So there are some 80%-clouds, some 95%-clouds, some 99.995%-clouds, and so on.

The point I was trying to make is that the degree to which a cloud achieves that promise is correlated to the size (and longevity, and homogeneity) of the deployment. The more man-years have gone into taking care of a given server type at a given DC, the more institutional knowledge is ready-at-hand to solve a problem on your machine of that type, and so the fewer issues become emergencies that break out of the "cloud" abstraction to require your attention.

And it was a reply to the parent precisely because a security problem is just such an "emergency" that represents a failure of institutional knowledge: I would much sooner trust AWS's KMS to not leak my private keys than I would trust a machine I was running myself to not leak my private keys. I'm a much worse sysadmin than AWS!

Re: When Solid State Drives Are Not That Solid

#112

Post by kuschku »

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…

I currently can not notice any performance degradation, and I bought the drive in may 2014, with no further updates. (Unless Arch Linux automatically applies firmware updates, but I doubt that)

Re: When Solid State Drives Are Not That Solid

#113

Post by stream_fusion »

I have one of the affected drives mentioned in the article in my development laptop - the Samsung SSD 850 PRO 512GB.

As one of the most expensive SSD drives available on the market, it was disconcerting to find dmesg -T showing trim errors, when the drive was mounted with the discard option. Research on mailing lists, indicated that the driver devs, believe it's a Samsung firmware issue.

Disabling trim in fstab, stopped the error messages. However it's difficult to get good information about whether drive performance or longevity may be impacted without the trim support.

Re: When Solid State Drives Are Not That Solid

#114

Post by stream_fusion »

Aardwolf wrote: post #70

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

I have the same drive in a laptop. There were lots of trim errors in the kernel logs, with debian so I ended up disabling trim.

Re: When Solid State Drives Are Not That Solid

#115

Post by ploxiln »

sdalfakj wrote: post #93
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…

Since you seem to be the higher voted and showing on top, could you update your bit about queued stuff with this https://news.ycombinator.com/item?id=9724192

I can no longer edit my comment.

I assumed that these drives had the same controller chip and the same firmware base as the consumer samsung SSDs, but with higher quality nand and some firmware tweaks. It's very hard to find technical details about these enterprise drives on the internet (compared to the consumer drives).

I guess the smartctl command proves it, these enterprise samsung SSDs do not have queued trim enabled.

It would make sense for enterprise drives to be more conservative and lag on feature set. But it's very surprising that enterprise drives are corrupted by original un-queued trim, they're supposed to have more validation, and that's a very common feature.

Re: When Solid State Drives Are Not That Solid

#116

Post by ploxiln »

ploxiln wrote: post #53
adamsurak wrote: post #45

Earlier quoted context omitted.

In this case the TRIM command was un-queued, which makes it worse.

It sounds to me like even when it's the fstrim utility, which uses some ioctl() to tell the kernel to trim free regions in a range on a filesystem, the kernel ends up causing the queued trim command to be used if available. The "blacklist" does not appear to have any constant to blacklist old-style trim, only NCQ_TRIM (and other odd stuff, most notably all NCQ usage). This makes sense, because if some SSD advertised…

I see the addendum to your post; touche, I guess these drives do indeed lack queued trim, and have some issue with plain old trim. That's rather surprising, to me... I was going to say "especially for an enterprise-grade drive" but I'm not so sure...

Re: When Solid State Drives Are Not That Solid

#117

Post by hvidgaard »

icebraining wrote: post #65
hvidgaard wrote: post #58

Earlier quoted context omitted.

The thing people forgets, is that the cloud provider have the same issues and expences. That cost is passed on to the clients. Now they may be more efficient ect. but once you reach a certain scale, and it's less that people think, you might as well get it done in house if you can find qualified people.

How can people forget, when that cost is right there in the price tag? If anything, it's easier to overlook the costs of running your own hardware, since they aren't immediately apparent.

They simply underestimate the ops cost, and often focus on the monthly cost. The thing that cloud providers like AWS are good at, and IMO, the only reason you should choose them, is when you have highly variable loads. Dynamic scaling is something only they can do because they have such a massive scale. Even if you're relative small and cannot justify hiring a sysadmin, there are plenty of consults out there you can hire.

Re: When Solid State Drives Are Not That Solid

#118

Post by hvidgaard »

agumonkey wrote: post #92
PythonicAlpha wrote: post #90

Earlier quoted context omitted.

I once was a huge fan of Samsung. But with the EVO disaster and this one, I really regret to have bought one of these.

The EVO was well covered, but these being from the PRO line it's even worse... Intel SSD have been praised for a long time, they seem the only stable brand around.

The latest EVO firmware have this issue as well, so it's probably a bug in their shared codebase for the controllers.

Re: When Solid State Drives Are Not That Solid

#119

Post by hvidgaard »

stream_fusion wrote: post #113

I have one of the affected drives mentioned in the article in my development laptop - the Samsung SSD 850 PRO 512GB. As one of the most expensive SSD drives available on the market, it was disconcerting to find dmesg -T showing trim errors, when the drive was mounted with the discard option. Research on mailing lists, indicated that the driver devs, believe it's a Samsung firmware issue. Disabling trim in fstab, stop…

Trim really is only a helpful message when the drive is near full so the GC can preemptively zero blocks and retain good write speed. Without trim, the firmware must wait until it gets a write for a particular block before it know it can be erased.

If your drive has reasonably with unprovisioned space, it can simply work around the missing trim commands - this however, is theory, I do not know if the firmware actually does this. This is the exact thing that makes some drives better than others when working without trim.

Re: When Solid State Drives Are Not That Solid

#120

Post by stream_fusion »

hvidgaard wrote: post #119
stream_fusion wrote: post #113

I have one of the affected drives mentioned in the article in my development laptop - the Samsung SSD 850 PRO 512GB. As one of the most expensive SSD drives available on the market, it was disconcerting to find dmesg -T showing trim errors, when the drive was mounted with the discard option. Research on mailing lists, indicated that the driver devs, believe it's a Samsung firmware issue. Disabling trim in fstab, stop…

Trim really is only a helpful message when the drive is near full so the GC can preemptively zero blocks and retain good write speed. Without trim, the firmware must wait until it gets a write for a particular block before it know it can be erased. If your drive has reasonably with unprovisioned space, it can simply work around the missing trim commands - this however, is theory, I do not know if the firmware actuall…

Thanks. I'll probably end up creating an unprovisioned partition. It's frustrating, exactly because of the uncertainty re future performance. Especially given the price premium for pro/enterprise level hardware.
Post reply on HN