 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
[ about ]
[ reasons ]
[ click of death ]
[ conclusion ]
[ aftermath ]
[ faq ]
[ links ]
[ back to klangraum subpage ]
[ home ]
last updated on 01.02.07 : very minor changes.
| about | 
|
|---|---|
|
Warning: Undefined array key "DOC_ROOT" in /users/pheuron/www/deathstar.php on line 45 This track consists of lots of hard disk noise, in normal or rather unfortunate conditions. It is kind of a transformation of the stuff that happened to me. The only non-hard disk parts are speech and a pc-typical power-on beep. | |
| reasons |
|
| [Here comes a lot of technical stuff. This may be extremely boring.] A long time ago, i decided to build a RAID-0* array to do audio editing in an acceptable amount of time. My choice fell on two IBM DTLA307030 disks (family Deskstar 75GXP), each with a capacity of 30 gigabyte spinning at 7200 rpm. Everything was fine then, they were amazingly fast and running smoothly. I was happy and stuffed them full with precious data. Seven months later: one day, i heard a very strange noise during some disk operation... | |
| The operating system got shocked and froze instantly. A test run of IBM's drive fitness test software revealed an error code of 0x70. I should get used to this soon.... Ok, shit happens, i thought. By this time, the array was filled 80%. I had to emergency-rescue all the stuff, which resulted in a 18 hours nonstop copy session onto the RAID array of a good fellow of mine via network. I dissected the array and sent the failed drive back to IBM. The remaining drive was reconfigured to run stand-alone. About one month later, this drive started to show the same symptoms. Another error code 0x70. My nervous system was really starting to heat up... But what choices were left? So i rescued all stuff gathered on this one and sent it to its masters. |  the empire doesn't seem to care about your data. |
|
Both disks were replaced by drives of the same type. In the meantime, i had found several hardware
forums on the web, where lots of people complained about just the same effect that had happened to me.
I wasn't really keen on continuing to risk my data, so i left them sealed and packaged, and sold them
as quick as possible. I decided to rebuild my RAID with the next generation of IBM drives, two
IC35L040AVER07. These are members of the Deskstar 60GXP family. We're talking about two 40 gb drives
at 7200 rpm, which add up to a lightning fast array of 80 gigabyte disk space. Just like with my
first array, everything was fine in the beginning. Six months later..... the ' click of death' stroke again. One of the drives went louder and louder in normal operation, presenting this quite awful noise, when trying to access two certain locations in the directory structure. Drive fitness test showed another error 0x70. I stopped myself closely before cleaving these 'quality drives' into pieces. The second RAID array, now filled by about 75%, went unstable. Time to rip it apart again. I spent about two weeks with compressing and burning the most important data to CD-R's. Boy, that was fun.. =( Some years ago, i sold computer parts. As they always had a perfect reputation before, i recommended IBM drives for new systems, especially the DTLA model. I feel guilty. I really don't like selling crap to innocent customers. Now, in the present time, as i write this, the -AVER model is history and has been replaced by the next family, called Deskstar 120GXP or -AVVA. I already noticed people complaining about the 'click of death' with these drives, too....... Update260802: Big blue has replaced the AVVA for the AVVN model. No records of its long term reliability have been found yet. | |
| the 'click of death' pattern from an IC35L040AVER07 |
Warning: Undefined array key "DOC_ROOT" in /users/pheuron/www/deathstar.php on line 107 mp3 (200kb / 12 seconds 128kbps mono) |
| conclusion |
|
|
All of the drive families mentioned above make use of IBM's GMR*
technology, which is the cutting edge of today's hard disk architecture. It helps to achieve a maximum
of data density per platter, resulting in very narrow tracks on the disk and high transfer rates. It
seems, that this, in conjunction with the heat caused by the platters rotating at 7200 rpm, is not as
easy to handle for the electronics as they thought. Although it is not a nice behaviour to let customers do the beta-testing (this happens with a lot of software as well..), errors can and will happen sometimes. I would not say a word, if it would be a concern for just one generation of drives, but here it is the case for three subsequent families. IBM did not lose one single word about this issue. The only thing they actually say, is that the Deskstar 120GXP is not meant to be used in a server role, where the drives would be in use 24/7. They ask you not to use it more than 8 hours a day. I nearly started to puke, as i heard this. It is in fact a very poor response from a big company that is about to loose its excellent reputation for having built many reliable drive families in the past. Comparing my experiences with those of other people, i was relatively lucky. Not much data was lost in the end, but a huge amount of time and nerves. My drives all failed about 7 months after deployment, still leaving me able to access and rescue most of the data on them. I saw brand new DTLA's, emitting the 'click of death' and being completely inaccessible. My next RAID most likely will not contain any IBM or hitachi drives. | |
| aftermath |
|
|
update15.01.03: The cause of the deathstar disaster has come to be known. When a DTLA or IC35..AVER drive is operated many hours a day, chances are, that the heads will catch a bit of the platter's lubricant coating. [yes, i know, this sounds somewhat stupid. It is a citation. Check out this for a related german newsflash on heise.de.] This leads to the well known 'noisy' bad sectors and error 0x70. To avoid this undesirable event, you can get a firmware upgrade for your drive, that will move the heads around from time to time while idling. First you will need a firmware identification utility to determine the required version. Note that it will only detect drives on the motherboard IDE channels. After running this tool, you will have a log file stating the URL to get the required updater. After applying it, your deathstar should be safe [within the known limits of hard drives]. | |
|
comments? similar experiences? send mail to deathstar3 at pheuron.de. I would like to thank all people who have replied and given me valuable feedback so far. | |
| faq - deathstar survival guide |
|
|
Q: my deathstar has just started to click at me. How should i rescue my data? Q: my deathstar clicks right from the start of my computer. It won't be shown on the BIOS screen. Is there any help? Q: my Deathstar has clicked. I formatted it with the IBM DFT and applied the firmware update. Is it safe now? Q: what firmware is suitable for my Hard disk? / Why are there contrary messages from the update identification utility and the corresponding updater? Q: What should i do with my returned drive from RMA? Q: Does the firmware update really prevent it from clicking? | |
|
Q: my IBM drive has just started to click at me. How should i rescue my data? A: - free and easy way: use convar's file recovery. - free but tedious way: use a filemanager like explorer, copying the data from the deathstar to a (hopefully) safer place. Some considerations first: As you already might have noticed, your Operating System may freeze, when it approaches a 'clicked', in other words bad sector. Win98 just does it like this. WinXP will not be able to access the deathstar partitions for the current session, thus still leaving you with the ability to safely reboot. I don't know how other OS'es would behave. If you do, please drop me a mail: deathstar3 at pheuron.de .. It is advisable to have really NO unneccesary programs running, since a spontaneous reboot will most likely mess up files and/or configuration data currently in use. Connecting the Deathstar to another system might be a good idea. Now copy your partition(s), proceeding from root dir by dir.. If you run into trouble while attempting to copy a certain directory, note it, reboot and continue with smaller parts from within, so that you end up with everything but the few really destroyed files. The amount of them will vary. This can be a very slow and tedious process, but if you're lucky, you haven't lost anything important at all.. Ofcourse, this approach only makes sense if your Deathstar is not the drive you're booting from. Another assumption would be, that the Deathstar file system still is functional. Advantage: no extra tools required. This procedure of course is possible as well from a Linux boot CD like Knoppix or Slax, thus giving you the further advantage to do it even on your system drive. - medium expensive way: use a recovery tool. Most of them will create or come as a bootable floppy disk. Programs reported to be working fine for Deathstars are GetDataBack (69$) and ACR MediaTools pro (150$). Be prepared for a ~10h-session including lots of clicks.. - very expensive way: send it to a hard disk recovery company like vogon, ontrack or similar. They will be able to recover almost all of the data, missing just the few kilobytes that have been physically scratched away. This operation can cost EUR/$ 1000 and more, so you should be sure if your data really is worth it.. [some small print stuff: I don't own any of the mentioned $$ tools. I also am in no way affiliated with any of their manufacturers, nor do i make money from mentioning them. They, as well as some free solutions, have been brought to my attention by kind visitors of this page, whom i'd like to thank.] | |
|
Q: my IBM drive clicks right from the start of my computer. It won't be shown on the BIOS screen.
Is there any help? A: unfortunately, your data will remain invisible for any operating system. Go for RMA, unless the data is important enough to risk the expensive approach in the answer above. | |
|
Q: My Deathstar has clicked. I formatted it with the IBM DFT and applied the firmware update. Is it
safe now? A: I am afraid, No. The process of 'clicking' is more or less a Headcrash, resulting in lots of debris flying around inside the Harddisk case, just waiting to settle down again on the platters - possibly being caught again by the heads, resulting in even more damage. The impact of a clicking Deathstar has been (frighteningly) documented in this autopsy. | |
|
Q: What firmware is suitable for my Hard disk? / Why are there contrary messages from the update
identification utility and the corresponding updater? A: Ask IBM/hitachi support; i don't know. Due to IBM's quite confusing firmware version naming habits, this is quite difficult to tell. My only surviving disk, an IC35L040AVER07 has been updated to v ER40A45A40 and has been running happily and click-free ever since. | |
|
Q: What should i do with my returned drive from RMA? A: Check if the firmware is up to date. If no, update ASAP! If yes, you may safely use it - unless it's a "serviceable used parts". Two further Notes: - IBM obviously has managed the legerdemain to send disks with old firmware. [applause! =( ]. So, checking it is ultra-important. - beware of "servicable used parts"! - these disks have been reported to fail subsequently and/or behave unreliable, even with new firmware. Perhaps they already experienced a click of Death, leaving the remains of it as a timebomb, that can go off on your data, anytime. If you really have to use one of these, please don't store important stuff on it at least.. | |
|
Q: Does the firmware update really prevent it from clicking? A: Yes. The drive mentioned here is actively cooled, in (almost) 24/7 use and fully operational. I will report any changes.. An Assumption is, that the disk never has clicked before. see also this question. | |
| You have a question not listed here? Found an error? mail to deathstar3 at pheuron.de. | |
| links |
|
| www.sheller.com/ibmclassaction.htm | View stuff about the ongoing class action suit against IBM. |
| www.storagereview.com | A review page for all kinds of hard drives (unfortunately they don't cover long term reliablity in their tests) with a quite interesting forum. Just search for '75GXP' or '60GXP' or '120GXP' there and you'll see.. |
| www.hitachigst.com/hdd/support/download.htm | former IBM's, now Hitachi's utilities download page. Here you will find the drive fitness test. The feature tool may be useful, too |
| www.hitachigst.com/warranty/ | Here you can check the warranty and / or RMA status, if you're an unlucky owner of their stuff. |
| www.hitachigst.com/hdd/desk/ds75gxp.htm | Info page about the Deskstar 75GXP, covering the DTLA 3070xx series |
| www.hitachigst.com/hdd/desk/ds60gxp.htm | Info page about the Deskstar 60GXP, covering the IC35 Lxxx AVER07 series |
| www.hitachigst.com/hdd/desk/ds120gxp.htm | Info page about the Deskstar 120GXP, covering the IC35 Lxxx AVVA07 series |
| www.overclockers.com.au/techstuff/a_hdd_anatomy/ | A view into the internals of a 'clicked' 75GXP |
| www-1.ibm.com/support/docview.wss?rs=0&q=DTLA&uid=psg1MIGR-44195 | Get the firmware update for your DTLA or IC35...AVER drive here |
| www.geocities.com/dtla_update/ or http://haque.net/dtla_update/ | useful collection of firmware tools and further links about the deathstar phenomenon |
| www.heise.de/newsticker/meldung/17368 babelfished into english |
related news on heise.de, a large german it news publisher |
| www.heise.de/newsticker/meldung/44774 babelfished into english |
more related german deathstar news |
| glossary |
|
|
RAID - Redundant Array of Independent Disks. On this page, i wrote especially about RAID-0, which means
two drives coupled together, with twice the capacity and nearly twice the transfer rate of a single
drive. The system sees this as one big and amazingly fast drive. There is no redundancy in this mode,
which means that, if one drive fails, all the data is inaccessible. GMR - Giant MagnetoResistive. IBM's latest technology to increase the data density per disk platter. See IBM's infopage | |
[ about ]
[ reasons ]
[ click of death ]
[ conclusion ]
[ aftermath ]
[ faq ]
[ links ]
[ back to klangraum subpage ]
[ home ]
|
|
|
|
|
|
|
|
|
|
this page has been created on 22.06.2002
last update: 01.02.2007
