Live data from Hacker News

ST3000DM001

en.wikipedia.org

61–70 of 259 posts

Re: ST3000DM001

#61
post #55
post #50

Earlier quoted context omitted.

Yeah maybe it was just for the construction kickbacks and the datacenter is actually empty.

Or they managed to fill it with hardware without having to coordinate an intricate conspiracy involving supply chain and manufacturers across the globe.

> coordinate an intricate conspiracy

Nobody is alleging that but you. Personally I don't think either "surveillance system needs a way to store what is collected" or "high-volume customers have economic leverage to demand confidentiality" are particularly intricate concepts.

Re: ST3000DM001

#62
post #61
post #55

Earlier quoted context omitted.

Or they managed to fill it with hardware without having to coordinate an intricate conspiracy involving supply chain and manufacturers across the globe.

> coordinate an intricate conspiracy Nobody is alleging that but you. Personally I don't think either "surveillance system needs a way to store what is collected" or "high-volume customers have economic leverage to demand confidentiality" are particularly intricate concepts.

[deleted]

Re: ST3000DM001

#63
post #48

Earlier quoted context omitted.

IIUC the same as in other contexts, the subtext being that in face of their refusal to replace these doomed HDs before a failure has registered, the failures were made to prematurely happen with a gentle stream of electrons.

Correct. To the other comments. We where a good customer that experienced an amazing stupidly high failure rate in a part that others also reported the same issue. The cost of deploying these systems and having them fail randomly broke planning and wasted the teams time and impacted our IT cost metrics. The cost of the support ticket, time and replacing and re-imaging a system was not free. We of course tried very ha…

I mean at first it sounded like fraud, but then you explained it, and then it really sounded like fraud.

Re: ST3000DM001

#64
Wow, what a coincidence. I did some maintenance on my NAS yesterday and finally removed one of my oldest hard drives, which I had unplugged a while ago because it was too noisy (it still worked when I unplugged it). I thought the name was familiar, I checked and yes, it is the very same model. I guess I was lucky not to lose any data on it, I wasn't very good with backups back when I first bought it.

Re: ST3000DM001

#66

I was responsible for maintaining some large glusterfs clusters built on top of these drives, and they certainly added excitement to the experience. 1) At one point we were experiencing disk failures often enough that we wrote a cronjob to detect drive failures via smartctl and automatically send an email to our hosting company requesting them replace the drive. This saved engineering time, and more importantly reduc…

These things always happen in the weekend don't they? When I managed a large network of servers, it seems that all the outages happened during parties and/or the weekend.

Re: ST3000DM001

#67
post #47
post #34

Earlier quoted context omitted.

This model was really bad, but he wasn’t wrong in general - while consumer drives have a higher failure rate, you can’t pretend the enterprise version can’t fail - and if you’ve built your system to withstand failure, whether 2 or 5 fail every year makes little difference if you have competent IT. I do make an effort to source them from as many different batches as possible, though - based on a DeskStar (“DeathStar”)…

> I do make an effort to source them from as many different batches as possible, though If you can, also stagger the initial power ons. There's a history of disk firmware bugs that are triggered by runtime; if it makes sense, you want to have enough of a difference in power on time to do a lossless replacement on your first disk before your second disk hits the magic number of time on.

Indeed.

Synology, which I’ve been using for the last 10 years or so when the project cannot afford NetApp/EMC class storage, does this out of the box. (I’m sure netapp and EMC do too, but it’s not my problem when the disks inside them fail)

Re: ST3000DM001

#68

I had three of these that died within 1.5 years of being new. Ugh.

Looking at my order history, I had one in my RAID and RMA'd it 1.6 years later. The replacement lasted until 2019 (4.5 years).

Re: ST3000DM001

#69

Earlier quoted context omitted.

The Thailand story was a cover for the NSA buying a huge number of drives for the new data facility in Utah.

The plausibility of a conspiracy theory diminishes as the number of people necessary to keep the secret increases. How many people work in Thailand's hard drive manufacturing plants? Hundreds? Thousands? How many people in the logistics channels? How many people are vending food to these employees? How many people in the US Government? Oh, and pulling this off would also require co-ordination with Thai Government. Th…

You overthink this. The flooding might not have led to a crisis alone if the NSA or any other big buyer didn't place a huge order at that time. You also don't need a conspiracy to keep the procurements of a government agency confidential.

Re: ST3000DM001

#70
post #22

I also remember the IBM Deskstar 75GXP, which was so unreliable it earned the nickname "Deathstar".

And then they cleaned up their act, sold to Hitachi and are now the most reliable disks under HGST brand, currently owned by WD. Somebody suggested you should buy disks from manufacturers that have relative recent history of a catastrophe. Those should be cutting less corners.

The problem with that strategy is there are only 2.5 HDD manufacturers.
Post reply on HN