Live data from Hacker News

ST3000DM001

en.wikipedia.org

231–240 of 259 posts

Re: ST3000DM001

#231
post #93

Earlier quoted context omitted.

Because of Big Santa (ie. parents). And that promptly fails when the cost of maintaining the Santa system gets too big (ie. as the child's mental faculties develop, plus as the child interacts with the outside world not controlled by the parents). So unless we all are living in a very well orchestrated NSA Truman show, it's unlikely that your argument applies.

Perhaps you should read Hogfather or Making Money by Terry Pratchett. In which the importance of the lies that society tells itself is touched upon. "All right," said Susan. "I'm not stupid. You're saying humans need... fantasies to make life bearable." REALLY? AS IF IT WAS SOME KIND OF PINK PILL? NO. HUMANS NEED FANTASY TO BE HUMAN. TO BE THE PLACE WHERE THE FALLING ANGEL MEETS THE RISING APE. "Tooth fairies? Hogfat…

Satirical fiction is probably not a great measuring stick to judge reality by.

Re: ST3000DM001

#232

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.

This is probably some joke that I just don't understand, but just to be clear: Are you saying that there either was no tsunami or that the NSA created the tsunami as a cover to buy harddrives?

They're implying that the tsunami did little to no damage to the hard drive factory.

Re: ST3000DM001

#233

So why did this drive fail? Has nobody dissected it to figure out exactly which component no longer functioned correctly?

A search through data recovery forums like hddguru.com (they tend to have a secretive "trade union" attitude, but some useful stuff leaks through...) and the Internet reveals some more info like this: https://www.recoveryforce.ca/forums/viewtopic.php?f=12&t=157 Most of them seem to be head problems, and there are some outright head crashes too. Seems like bad media (leading to head failure) is mainly to blame: https:…

Huh. So many fixes in there are listed as 'replace head(s)'. I didn't realize that was a common fix for hard drives, thinking it would require near cleanroom conditions to ensure no dust got into the drive as its being worked on, and that it would be much cheaper/faster to maintain backups and swap in a new drive.

Re: ST3000DM001

#234
post #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.

> These things always happen in the weekend don't they?

Thats because servers know.... oh they know. Tuesday morning when you get into the office? Naw... that's too easy. Let's shit the bed on Christmas morning at 3:49am. That will let those stupid humans know who is boss around here.

Re: ST3000DM001

#235
post #93

Earlier quoted context omitted.

Because of Big Santa (ie. parents). And that promptly fails when the cost of maintaining the Santa system gets too big (ie. as the child's mental faculties develop, plus as the child interacts with the outside world not controlled by the parents). So unless we all are living in a very well orchestrated NSA Truman show, it's unlikely that your argument applies.

If large organizations can't keep secrets, then what are the names of the ten most important CIA personnel operating in Canada right now?

The difference is whether the entire organisation would have to know or not. "Actually, our HDD factory is operating" is both a thing that lots of employees would necessarily know (unlike CIA assignments in Canada), and also those employees would not be as trusted as high level intelligence agency operators. Particularly for low level employees, like contracted cleaners or whatever "Don't tell anyone the factory is operating" seems like it would be a great way to get the information out there that it actually is.

Re: ST3000DM001

#236

Back in the mid 90s I was working in IT at a midsized company. We used Compaq desktops (this is the Pentium Pro timeframe). The HD in the system where quantum fireball (IIRC). They failed at an amazing rate all in the first 3 months (30%). We called Compaq at one point and said, look we want replacement drives for all of our remaining systems. After much back and forth (stupid on their part as we had 1000+ machines o…

Had a similar experience at a previous job. I'd debugged a problem with one system down to a flaky drive, which I extracted and took to our sysadmin. Without hesitation, he slammed it down on the floor. "It's not flaky now." The thing is, I knew a lot more than he did about how hard drives work, but he knew a lot more about how vendors work. A flaky drive might be hard to replace. A dead one wouldn't. Lesson learned.

My boss at a drug store did the same thing to a moderately damaged case of product X (no longer remember). He dropped it a few times and made sure it was unequivocally damaged and called the vendor.

Re: ST3000DM001

#237
post #235

Earlier quoted context omitted.

If large organizations can't keep secrets, then what are the names of the ten most important CIA personnel operating in Canada right now?

The difference is whether the entire organisation would have to know or not. "Actually, our HDD factory is operating" is both a thing that lots of employees would necessarily know (unlike CIA assignments in Canada), and also those employees would not be as trusted as high level intelligence agency operators. Particularly for low level employees, like contracted cleaners or whatever "Don't tell anyone the factory is o…

You tell the employees that they are working for a HDD factory. A small number of people at the top of the company are in on it and keep sales limited to one or a small number of clients, all of whom are the clandestine buyer.

That would be similar to the way in which the fake Swiss cryptographic machine manufacturer was run. Their only leak risks were from employees who realized that their cryptosystem was easily broken. An HDD manufacturer would not have that problem because all of its work would be perfectly legitimate.

https://en.wikipedia.org/wiki/Crypto_AG

Re: ST3000DM001

#238

Earlier quoted context omitted.

Every time a submission like this pops up I expect someone who worked at Seagate during that era to pipe up and explain what went wrong and why ... but I haven't seen it yet. Surprising.

I think it's sad that the hacker/maker community doesn't have enough knowledge/skill/inclination to disassemble this kind of thing and figure it out for themselves. It's a bad sign when tech complexity gets out of the expertise of a hobbyist - I believe that's the start of a stagnation of that technology as new young engineers never get excited about disassembling and modding hard drives in their free time, and in tu…

The technical answer of what part failed and why is only a small part of the overall answer, though.

For example, with the Challenger explosion, it's O-rings vs. the culture and organizational deficits that led to: the O-rings, failure to revise the seal structure despite evidence of problems on prior launches, and the final decision to launch Challenger.

All of that is arguably the most interesting part.

Re: ST3000DM001

#239
post #11

I remember these, zpool history provides a nice record here. First one failed within a year! zpool history tank | grep "zpool create\|replace" 2013-03-26.23:27:40 zpool create -fo cachefile=/var/tmp/zpool.cache -o altroot=/mnt tank raidz2 gpt/disk0.nop gpt/disk1.nop gpt/disk2.nop gpt/disk3.nop 2014-01-18.19:00:41 zpool replace tank /dev/gpt/disk3 2014-01-19.09:59:45 zpool replace tank /dev/gpt/disk1 2014-11-30.14:44:…

> zpool history

TIL this exists. Neat!

Re: ST3000DM001

#240

I have 1 of these still in an array and my second to last one died a few weeks ago. They had high failure rates for sure but some of them held on for a good 5+ years for me. All of these drives came from shucking and a little over a year ago I moved from Seagate externals to WD externals and my pain increased 10-fold. Not only did I have to deal with the 3.3V pin issue but I've had drives die in under a year. Since t…

> I have 1 of these still in an array and my second to last one died a few weeks ago

Exact same story here.

With the exception of one of the Seagates that did die really early (I certainly wouldn't recommend them given their track record but it does seem this issue is a tad overblown.

Post reply on HN