[deleted]
When Solid State Drives Are Not That Solid
71–80 of 123 posts
Re: When Solid State Drives Are Not That Solid
#72I'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 h…
I've done similar over the last three years and had good luck with the Crucial drives. However if you take a look at the Linux Kernel patch they link to (search for "don't properly handle queued TRIM"):
https://github.com/torvalds/linux/blob/e64f638483a21105c7ce3...
There are Crucial SSDs on the list. I'm going to be keeping a closer eye on them now.
Re: When Solid State Drives Are Not That Solid
#73I'm so sick of this TRIM. Constant configurations needed because of it, constant care like "this thing you better don't do on SSDs". And then problems like this.
Do you think there'll ever be SSDs that don't need it?
Re: When Solid State Drives Are Not That Solid
#74Earlier 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…
> 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.
Re: When Solid State Drives Are Not That Solid
#75I'm so sick of this TRIM. Constant configurations needed because of it, constant care like "this thing you better don't do on SSDs". And then problems like this. Do you think there'll ever be SSDs that don't need it?
[deleted]
Re: When Solid State Drives Are Not That Solid
#76Earlier 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.
My experience is that people don't understand cloud pricing at all.
First of all they tend to not look at monthly prices, and are seduced into thinking their instances are cheap. Secondly they are seduced itnto thinking they are spending less ops time, though in my experience it's the reverse. Thirdly, people "forget" about extras like bandwidth costs (which are extortionate at all the big cloud providers), extra storage volumes etc.
Then when people get the bill, it often gets back-rationalised as being ok because it's cloud so it must be cheap.
The greatest innovation AWS did was finding a way to get people to pay absolutely insane rates for hosting.
Re: When Solid State Drives Are Not That Solid
#77Earlier quoted context omitted.
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.
Heh, i still recall my early encounters with Linux and reading the bootup messages. One of them contained a line related to having found a CPU bug and having put a workaround in place. I am not entirely sure, but i think it may have been the F00F bug. https://en.wikipedia.org/wiki/Pentium_F00F_bug
Ha. Reminded me of the Pentium Floating Point Bug from the 90s. First (only?) time a CPU bug has been an international press story?
Re: When Solid State Drives Are Not That Solid
#78Earlier quoted context omitted.
Is the loss of reputation really worth less than the value of the externalised testing?
Loss of reputation isn't a real thing in this industry. Pretty much all hard drive manufacturers have had high-profile "bad" models, for example.
It's a real enough thing that the IBM DeathStar incident [1] [2] was a large factor in making IBM exit the harddisk market (sold off to Hitachi)
Re: When Solid State Drives Are Not That Solid
#79Wow, that sucks. Another reason to use ZFS – you’d notice the corrupted files a lot sooner.
Or run a verification layer on top of whatever FS you use (e.g. running git fsck would discover corruption in your git indexed files too).
Re: When Solid State Drives Are Not That Solid
#80Earlier quoted context omitted.
Loss of reputation isn't a real thing in this industry. Pretty much all hard drive manufacturers have had high-profile "bad" models, for example.
It's a real enough thing that the IBM DeathStar incident [1] [2] was a large factor in making IBM exit the harddisk market (sold off to Hitachi) [1] https://en.wikipedia.org/wiki/HGST_Deskstar [2] http://www.astro.ufl.edu/~ken/crash/index.html
But they're still in business making hard drives, under the DeskStar name. Seagate had a round of failures at one point. I'm sure there are people out there who've sworn off WD as well.