A bad block is a bad block - it's marked corrupted and that block's LBA address is reassigned to a replacement block on the end of the track. Once a block is reallocated, it's as though the old block doesn't exist according to the firmware. The driver won't help you at all - the old block no longer even has an LBA address. I guess it still have a physical address that may be accessed if you know what you're doing, but that'sa bit over my head at this point.
Very possibly! It could have forced a new write of the log and bypassed the bug. Other people are reporting that the drive comes up again if power cycled a few times... so i think you may have gotten lucky in that respect.
As far as I know, no drives with 3.AAJ are affected. Keep an eye on the KB article though - if your model shows up there, then call in and see whats going on, no matter your firmware.
Sadly, this is kinda the downside of the corporate push to be the first to have the fastest, highest capacity drives on the market.:(
Drives die, dude. Some drives last a decade, others are dead out of the box. Backup, Backup, Backup. If your data's important to you, you should have at least 2 copies or more on different media. Internal harddrive, backed up to an external harddrive once a week is good enough for most people. Not foolproof, but good enough. I'd say this weather I worked for Seagate, IBM, Hitachi, or WD. Back your important data up - all drives fail eventually.
1 word: Lawsuits. if they gave incorrect information, it could open them up for liability if people acted o that information. When a business' data could be worth millions, one slip-up could cost them dearly. The only reason this firmware isn't such an issue, because of the disclaimers allover the place when you flash a drive.
yes, the 1.5Tb drives both stutter and are at risk of bricking due to the journal issue. The Stuttering issue is fairly recent and mostly runs in the 1.5tb drives - but the journal issue is older and exists across many 7200.11 drives. ES2 drives and Diamondmax drives.
SD1A fixes both of these problems in the 1.5Tb drives.
The your drive can most likely be saved without RMAing it.
Call in - Explain the situation, ask for a team lead or supervisor. Explain that your drive can still be seen in the BIOS and the SD1A flash utility can still detect and flash the drive, and push hard to get the earlier revision of your firmware.
A procedure which would work better would be to make the patcher recognize whether the firmware is appropriate to the drive, and just refuse to run it if it is running against the wrong drive. Like basically everyone else on the planet. Even your average wifi router has an id in its flash format.
I absolutely agree with you. There's been plenty of "People are *used* to flashing hardware by now. why don't we just have a decent flash utility, and a big disclaimer?"
What I think's happened here, is that being restrictive with firmware became the norm - WD, Hitachi, IBM are all the same way. Maybe there's a reason I haven't figured out yet, but I suspect it has to do with the fact that your data is on the drive.
You brick a router, you're offline until you get it replaced. You brick your mobo, your computer's down. You brick your HDD, you actually lose access to your data, which is often worth far more then the computer itself.
That's fucking stupid. When the drive errors heavily, it can get into a state where it just disappears? That's a support NIGHTMARE.
You misunderstand. *ONLY* if the drive is powered down having just written the 320th log file. After Log file #320, it rolls back around and overwrites log file #1. So, on Log files 1-319, you're okay. only in the case that it has just written Log #320 AND is power cycled, will it lock up. If it is on #319 or rolled around to #1, then it's fine. Ine in a million chance.
In this case, "caught with their pants down" is "caught being incompetent".
A quick fix is even more necessary right now. The people abused by this are the people who buy the big disks. That's not the group you want to alienate.
A "Quick Fix" is exactly what ended up bricking all these drives while trying to solve an infrequent issue that affects a very small number of people due to it's unlikeliness to actually happen. What was needed was a well tested and better engineered fix.
First, let me apologize, I'm gong to withhold employment details such as tenure and experience mostly due to the fact that many of us at Seagate (including some in management) are Slashdot regulars.
That said, I really do enjoy my time at Seagate, and it has been an absolutely wonderful company to work for.
As far as "BRINKS" "MOOSE" "GALAXY" etc.. are concerned, they are pretty much the internal development names of the drive family. There can be overlap, but most "BRINKS" drives are 7200.11, I believe, while "MOOSE" drives are almost all 7200.10, and "GALAXY" drives are 7200.9. Generally, those names don't make it out into public, but if you were to tear into the SD1A firmware, you'll notice that it looks for the "BRINKS" drive before it flashes the firmware to the drive. There can be different internal names for different revisions of the drive itself, but generaly they stick to one revision per family - a new internal name would only be used for a MAJOR revision on the drive.
I don't have my documentation handy, but I'll look that up later in the week and try to give you a better answer.
Thank you! I wish this information would have been public and I didn't have to create a new account to avoid being fired for releasing 'confidential information' - but what can you do with jerkoff lawyers tearing at your corporate heels already?
Now, to your questions!
1) It keeps changing because the scope of the issue keeps changing. I'm pretty sure it's a range of drives within the familys noted in the KB article - but also, there are some external drives affected because they contain an internal drive with the problem, that aren't on the article yet. Your best bet would be to compare your drive to the list of models, and then wait a little while.. around friday, I *think* they should have most issues sorted out and the information accurate. But I can't promise anything.
2) That could very well be it. I'm not privy to the nitty-gritty details, as engineering clammed up pretty quickly - I'm just a geek enough to understand what I hear in passing or the few technical details I came across when I go looking for information. But the mysterious death log being a SMART self-test log would absolutely make sense, and is consistent with what I'm hearing.
3) Unofficially, I've seen more then just the 1.5Tb drives display symptoms similiar to the stuttering issue, but none so blatent or as impacting as it is in the 1.5Tb drives.
As far as the firmware fixing both the stuttering issue and the unresponsive-drive issue, yes. The changes for the stuttering issue was made in CC1H and SD1A firmwares. Any firmware equal or more recent then those two, will have the fix for both issues.
4) I have no idea. SMART characteristics can vary from part number to part number - or even sometimes drive-to-drive; so what is 'out of tolerances' for one part number could be just fine for a different p/n (even though they are the same model number).
Nope. It's stored on a part of the drive you can't access without really knowing your shit... of course, at that point you could unbrick the drive yourself.
I've worked tech support for a while now, and that's something that's struck me working for seagate. Just about everyone there actually.. well, -cares- about what they do. The atmosphere inside is completely different then say, dell or cox or AT&T (from what I hear - I've never worked at any of those places, but many of my coworkers have).
The management lets support agents have license to use their experience and skills in fixing issues, instead of reading from a script. They don't heavy-hand them, and they are more concerned in fixing an issue in as few of calls as possible, then caring about the number of calls taken a day or keeping the calls as short as possible. It means that tech support can actually *fix* the problem instead of trying to get people off the phones as fast as possible.
And thanks, always glad to hear the positive feedback.
As far as I know, if your drive has the CC1G, CC1H, CC1J or any of the CC firmwares really, it is completely unaffected by this issue. However, it may need an update if you experience 'stuttering' (the drive pausing for more then a few seconds during data transfer). The CC1H and CC1J firmwares are *fine* and will absolutely not brick your drive.
I'd still wait a little while though - support is overwhelmed and mistakes are being made as noone is used to these changes. Once everyone gets a routine down (once there -is- a routine at all), they'll be better able to help reliably.
Wait a few days - Seagate will have in place a procedure to get bricked drives due to a bad firmware, in place. Once they do, you should just be able to send them the drive and it'll be reflashed with good firmware and sent back. I can't say this for absolute certain, but that's what they're telling us now.
If you have confidential data on the drive, you have two options:
a) if you send it in for a reflash, there will be a tech who flashes the drive using a serial interface, and then verifies good read/writes to the data. But he's likely unbricking a hundred drives a week, and doesn't care about what's on the drive unless he happens to maybe notice a folder when he does he read/write test labled "OMG HUGE AMOUNT OF CHILD PORNOGRAPHY". I can't even say that a person will even be doing the R/W test - but there is that chance.
or b) RMA your drive. The first thing that happens once the drive passes a visual inspection (verifying that the warranty is still valid and the drive hasn't been user-damaged physically) is the drive is thrown on a text machine. if the drive passes the physical tests, then it's firmware is flashed and the diag machine goes through a 7 pass zero-random-zero-random cycle that destroys any and all data on the drive. This not only ensures data wipe, but also helps diagnose any read/write errors on the drive. If you RMA the drive, it's not even hooked up to a human-accessable 'computer' (just diag equipment) until the next customer who received the drive as a refurb, puts it in their computer - at which point it should be so blank, not even the government could recover data from it using the most advanced tech that we know about.
Call back and push your way up to a supervisor, and see what they offer you on friday, since the agent sent you the wrong firmware.
The known issue manifests itself where the drive spins up fine but either reports no data to the drive controller (or BIOS if applicable) or shows up with zero capacity.
If the drive isn't on This list, then it isn't affected. It won't even have the same firmware.
I can't encourage this, but if your drive has failed, you may try to swap the PCB. There are third-party parts suppliers that can sell you a replacement PCB (search for "PCB replacement" in google) - just make sure that the part number of the PCB matches *exactly* to your current drive, and if at all possible, match the firmware revision. But this is really hit or miss. It does have the potential to mess up any data on the drive and remove any chance of getting your data off he drive... *but* conversely, it may fire right up and work, or simply not do anything at all.
I've been a denizen of slashdot for many years - I just wish all these mod points were on my main account!:) But it is nice to be able to contribute knowledge and experience back to the community for once.
Thing is, this issue -is- rare. But it manifests itself in a way that's hard to distinguish from a normal drive failure. (suddenly no detection in the BIOS; spins up but never is seen on the computer - this can happen for a dozen reasons including a loose or bad cable, physical drive failure, etc) so a whole lot of 'me toos' doesn't mean much. When this issue potentially affects millions of drives, a >.01 chance of failure still adds up to thousands of drives.
I'll say this. There is no *more* chance of it dying on your next boot up then here has been of it dying your last 3000 boot ups.
Many people have noted that drives do tend to fail in batches. If there is some slight manufacturing error that causes a drive to fail, it tends to also exist in other drives from that same lot, the closer to the same manufacture time, the more likely it is to also fail. I tend to agree with them - it would make sense to me that if a photo lithography machine got bumped or a slight bad mix in the emulsion for etching the PCBs were present, it would affect all drives around the same build time.
I agree. The thing is, apparently this bug's been around for.. well.. a very, very long time and affects millions of drives. But it's so infrequent, it wasn't until lately there was enough drives with the same issue to catch the attention of the engineers.
To be honest, I am not sure at all why they even announced it, other then it's discovery followed so closely on the heels of the 1.5tb stuttering issue. I can only guess that it was to alleviate potential lawsuits caiming they 'withheld' the information about there being a known bug.
I absolutely agree with you. If we had been allowed proper development and proving time, this may not have been an issue at all. But the moment Seagate even admitted there was an firmware issue with the 1.5Tb drives, lawyers began recruiting for class action suits.
As I've noted below, it was an emergency release that shouldn't have been, and was never designed for release to the general public.
They should have redesigned the delivery system, but there was too much public pressure on them to get a fox out *now*...
But then again, it was somewhat their own damn fault - if they had just came out an explained the details of the issue to everyone instead of keeping it in-house, people would have realized quickly it wasn't as dangerous a situation as it seems at first glance. Just inconvenient to the few who run into it more then anything. But the ambulance chasing lawyers smelled blood during the 1.5Tb issue and forced management into a hole.
Just remember, everything dies
I sincerely smile in relief every time I hear someone other then myself say that phrase. It's a sign of someone who truely 'gets it' as far as hardware is concerned.
Thing is, I know Seagate really does try to push for high manufacturing standards (for example, did you know that every last Refurb drive *must* go through the full new-drive qualification before it's sent out? - something only a percentage of actual new drives have to go through because it's time consuming).
But WD and Hitachi and most other HDD companies have only slightly worse failure rates, negligible difference in failures really in the grand scheme of things. No matter if you go with WD, Seagate, Hitachi, IBM.... whatever. If there isn't an outstanding issue, then you're really looking at about the same chance of failure no matter which you buy.
The real decision is more 'how easy will it be to replace this if it fails?'
Funny though, I have in my system a 250Gb WD drive, that used to be in an external enclosure, until the USB interface controller died and I ripped the drive out - and now, after about a year of use, the internal drive's starting to fail... I rolled the crapshoot on this drive it seems.:)
I'll answer your questions to the best of my ability, and as honestly as I can!
I'm no statistician, but the 'drive becoming inaccessable at boot-up' is pretty much a very slim chance - but when you have 10 million drives in the field, it does happen. The conditions have to be just right - you have to reboot just after the drive writes the 320th log file to the firmware space of the drive. this is a log file that's written only occasionally, usually when there are bad sectors, missed writes, etc... might happen every few days on a computer in a nin-RAID home use situation.. and if that log file is written even one time after the magic #320, it rolls over the oldest file kept on the drive and there's no issue. It'll only stop responding IF the drive is powered up with log file #320 being the latest one written... a perfect storm situation.
IF this is the case, then seagate is trying to put in place a procedure where you can simply ship them the drive, they hook it up to a serial controller, and re-flashed with the fixed firmware. That's all it takes to restore the drive to operation!
As for buying new drives, that's up to you. None of the CC firmware drives were affected - only the SD firmware drives. I'd wait until later in the week, maybe next week, until they have a known working and properly proven firmware update.
If you were to have flashed the drives with the 'bad' firmware - it would disable any read/write functions to the drive, but the drive would still be accessible in BIOS and a very good chance that flashing it back to a previous SD formware (or up to the yet to be released proven firmware) would make it all better.
Oh, and RAID0 scares me by it's very nature... not an 'if' but 'when' the RAID 0 craps out and all data is lost - but I'm a bit jaded from too much tech support!:)
Slashdot Mirror
A bad block is a bad block - it's marked corrupted and that block's LBA address is reassigned to a replacement block on the end of the track. Once a block is reallocated, it's as though the old block doesn't exist according to the firmware. The driver won't help you at all - the old block no longer even has an LBA address. I guess it still have a physical address that may be accessed if you know what you're doing, but that'sa bit over my head at this point.
Very possibly! It could have forced a new write of the log and bypassed the bug. Other people are reporting that the drive comes up again if power cycled a few times... so i think you may have gotten lucky in that respect.
Yeahh.. about that.
Chat is *not* where we keep our brightest agents.
I'll leave it at that.
As far as I know, no drives with 3.AAJ are affected. Keep an eye on the KB article though - if your model shows up there, then call in and see whats going on, no matter your firmware. Sadly, this is kinda the downside of the corporate push to be the first to have the fastest, highest capacity drives on the market. :(
Drives die, dude. Some drives last a decade, others are dead out of the box. Backup, Backup, Backup. If your data's important to you, you should have at least 2 copies or more on different media. Internal harddrive, backed up to an external harddrive once a week is good enough for most people. Not foolproof, but good enough. I'd say this weather I worked for Seagate, IBM, Hitachi, or WD. Back your important data up - all drives fail eventually.
1 word: Lawsuits. if they gave incorrect information, it could open them up for liability if people acted o that information. When a business' data could be worth millions, one slip-up could cost them dearly. The only reason this firmware isn't such an issue, because of the disclaimers allover the place when you flash a drive.
yes, the 1.5Tb drives both stutter and are at risk of bricking due to the journal issue. The Stuttering issue is fairly recent and mostly runs in the 1.5tb drives - but the journal issue is older and exists across many 7200.11 drives. ES2 drives and Diamondmax drives.
SD1A fixes both of these problems in the 1.5Tb drives.
Are You??
The your drive can most likely be saved without RMAing it.
Call in - Explain the situation, ask for a team lead or supervisor. Explain that your drive can still be seen in the BIOS and the SD1A flash utility can still detect and flash the drive, and push hard to get the earlier revision of your firmware.
A procedure which would work better would be to make the patcher recognize whether the firmware is appropriate to the drive, and just refuse to run it if it is running against the wrong drive. Like basically everyone else on the planet. Even your average wifi router has an id in its flash format.
I absolutely agree with you. There's been plenty of "People are *used* to flashing hardware by now. why don't we just have a decent flash utility, and a big disclaimer?"
What I think's happened here, is that being restrictive with firmware became the norm - WD, Hitachi, IBM are all the same way. Maybe there's a reason I haven't figured out yet, but I suspect it has to do with the fact that your data is on the drive.
You brick a router, you're offline until you get it replaced. You brick your mobo, your computer's down. You brick your HDD, you actually lose access to your data, which is often worth far more then the computer itself.
That's fucking stupid. When the drive errors heavily, it can get into a state where it just disappears? That's a support NIGHTMARE.
You misunderstand. *ONLY* if the drive is powered down having just written the 320th log file. After Log file #320, it rolls back around and overwrites log file #1. So, on Log files 1-319, you're okay. only in the case that it has just written Log #320 AND is power cycled, will it lock up. If it is on #319 or rolled around to #1, then it's fine. Ine in a million chance.
In this case, "caught with their pants down" is "caught being incompetent".
A quick fix is even more necessary right now. The people abused by this are the people who buy the big disks. That's not the group you want to alienate.
A "Quick Fix" is exactly what ended up bricking all these drives while trying to solve an infrequent issue that affects a very small number of people due to it's unlikeliness to actually happen. What was needed was a well tested and better engineered fix.
First, let me apologize, I'm gong to withhold employment details such as tenure and experience mostly due to the fact that many of us at Seagate (including some in management) are Slashdot regulars.
That said, I really do enjoy my time at Seagate, and it has been an absolutely wonderful company to work for.
As far as "BRINKS" "MOOSE" "GALAXY" etc.. are concerned, they are pretty much the internal development names of the drive family. There can be overlap, but most "BRINKS" drives are 7200.11, I believe, while "MOOSE" drives are almost all 7200.10, and "GALAXY" drives are 7200.9. Generally, those names don't make it out into public, but if you were to tear into the SD1A firmware, you'll notice that it looks for the "BRINKS" drive before it flashes the firmware to the drive. There can be different internal names for different revisions of the drive itself, but generaly they stick to one revision per family - a new internal name would only be used for a MAJOR revision on the drive.
I don't have my documentation handy, but I'll look that up later in the week and try to give you a better answer.
Finally, thank you for your kind comments.
Funny, we too made that exact joke when out phones crashed the first time! :)
"OKAY! Who Flashed the PBX with SD1A?"
Everyone has their personal manufacturer blacklist due to personal experience or anecdote. I can't say I blame you!
Thank you! I wish this information would have been public and I didn't have to create a new account to avoid being fired for releasing 'confidential information' - but what can you do with jerkoff lawyers tearing at your corporate heels already?
Now, to your questions!
1) It keeps changing because the scope of the issue keeps changing. I'm pretty sure it's a range of drives within the familys noted in the KB article - but also, there are some external drives affected because they contain an internal drive with the problem, that aren't on the article yet. Your best bet would be to compare your drive to the list of models, and then wait a little while.. around friday, I *think* they should have most issues sorted out and the information accurate. But I can't promise anything.
2) That could very well be it. I'm not privy to the nitty-gritty details, as engineering clammed up pretty quickly - I'm just a geek enough to understand what I hear in passing or the few technical details I came across when I go looking for information. But the mysterious death log being a SMART self-test log would absolutely make sense, and is consistent with what I'm hearing.
3) Unofficially, I've seen more then just the 1.5Tb drives display symptoms similiar to the stuttering issue, but none so blatent or as impacting as it is in the 1.5Tb drives.
As far as the firmware fixing both the stuttering issue and the unresponsive-drive issue, yes. The changes for the stuttering issue was made in CC1H and SD1A firmwares. Any firmware equal or more recent then those two, will have the fix for both issues.
4) I have no idea. SMART characteristics can vary from part number to part number - or even sometimes drive-to-drive; so what is 'out of tolerances' for one part number could be just fine for a different p/n (even though they are the same model number).
Nope. It's stored on a part of the drive you can't access without really knowing your shit... of course, at that point you could unbrick the drive yourself.
THANK YOU
I'd mod you up to 11 if I could.
I've worked tech support for a while now, and that's something that's struck me working for seagate.
Just about everyone there actually.. well, -cares- about what they do. The atmosphere inside is completely different then say, dell or cox or AT&T (from what I hear - I've never worked at any of those places, but many of my coworkers have).
The management lets support agents have license to use their experience and skills in fixing issues, instead of reading from a script. They don't heavy-hand them, and they are more concerned in fixing an issue in as few of calls as possible, then caring about the number of calls taken a day or keeping the calls as short as possible. It means that tech support can actually *fix* the problem instead of trying to get people off the phones as fast as possible.
And thanks, always glad to hear the positive feedback.
As far as I know, if your drive has the CC1G, CC1H, CC1J or any of the CC firmwares really, it is completely unaffected by this issue.
However, it may need an update if you experience 'stuttering' (the drive pausing for more then a few seconds during data transfer). The CC1H and CC1J firmwares are *fine* and will absolutely not brick your drive.
I'd still wait a little while though - support is overwhelmed and mistakes are being made as noone is used to these changes. Once everyone gets a routine down (once there -is- a routine at all), they'll be better able to help reliably.
They still do. :)
They just fucked up the firmware fix on this issue.
Wait a few days - Seagate will have in place a procedure to get bricked drives due to a bad firmware, in place. Once they do, you should just be able to send them the drive and it'll be reflashed with good firmware and sent back. I can't say this for absolute certain, but that's what they're telling us now.
If you have confidential data on the drive, you have two options:
a) if you send it in for a reflash, there will be a tech who flashes the drive using a serial interface, and then verifies good read/writes to the data. But he's likely unbricking a hundred drives a week, and doesn't care about what's on the drive unless he happens to maybe notice a folder when he does he read/write test labled "OMG HUGE AMOUNT OF CHILD PORNOGRAPHY". I can't even say that a person will even be doing the R/W test - but there is that chance.
or b) RMA your drive. The first thing that happens once the drive passes a visual inspection (verifying that the warranty is still valid and the drive hasn't been user-damaged physically) is the drive is thrown on a text machine. if the drive passes the physical tests, then it's firmware is flashed and the diag machine goes through a 7 pass zero-random-zero-random cycle that destroys any and all data on the drive. This not only ensures data wipe, but also helps diagnose any read/write errors on the drive. If you RMA the drive, it's not even hooked up to a human-accessable 'computer' (just diag equipment) until the next customer who received the drive as a refurb, puts it in their computer - at which point it should be so blank, not even the government could recover data from it using the most advanced tech that we know about.
Call back and push your way up to a supervisor, and see what they offer you on friday, since the agent sent you the wrong firmware.
Did it stop physically spinning up?
The known issue manifests itself where the drive spins up fine but either reports no data to the drive controller (or BIOS if applicable) or shows up with zero capacity.
If the drive isn't on This list, then it isn't affected. It won't even have the same firmware.
I can't encourage this, but if your drive has failed, you may try to swap the PCB. There are third-party parts suppliers that can sell you a replacement PCB (search for "PCB replacement" in google) - just make sure that the part number of the PCB matches *exactly* to your current drive, and if at all possible, match the firmware revision. But this is really hit or miss. It does have the potential to mess up any data on the drive and remove any chance of getting your data off he drive... *but* conversely, it may fire right up and work, or simply not do anything at all.
I've been a denizen of slashdot for many years - I just wish all these mod points were on my main account! :)
But it is nice to be able to contribute knowledge and experience back to the community for once.
Thing is, this issue -is- rare. But it manifests itself in a way that's hard to distinguish from a normal drive failure. (suddenly no detection in the BIOS; spins up but never is seen on the computer - this can happen for a dozen reasons including a loose or bad cable, physical drive failure, etc) so a whole lot of 'me toos' doesn't mean much. When this issue potentially affects millions of drives, a >.01 chance of failure still adds up to thousands of drives.
I'll say this. There is no *more* chance of it dying on your next boot up then here has been of it dying your last 3000 boot ups.
Many people have noted that drives do tend to fail in batches. If there is some slight manufacturing error that causes a drive to fail, it tends to also exist in other drives from that same lot, the closer to the same manufacture time, the more likely it is to also fail. I tend to agree with them - it would make sense to me that if a photo lithography machine got bumped or a slight bad mix in the emulsion for etching the PCBs were present, it would affect all drives around the same build time.
Who knows.
I agree. The thing is, apparently this bug's been around for.. well.. a very, very long time and affects millions of drives. But it's so infrequent, it wasn't until lately there was enough drives with the same issue to catch the attention of the engineers.
To be honest, I am not sure at all why they even announced it, other then it's discovery followed so closely on the heels of the 1.5tb stuttering issue. I can only guess that it was to alleviate potential lawsuits caiming they 'withheld' the information about there being a known bug.
I absolutely agree with you.
If we had been allowed proper development and proving time, this may not have been an issue at all.
But the moment Seagate even admitted there was an firmware issue with the 1.5Tb drives, lawyers began recruiting for class action suits.
Disgusting ambulance chasing fecal sniffers.
As I've noted below, it was an emergency release that shouldn't have been, and was never designed for release to the general public.
They should have redesigned the delivery system, but there was too much public pressure on them to get a fox out *now*...
But then again, it was somewhat their own damn fault - if they had just came out an explained the details of the issue to everyone instead of keeping it in-house, people would have realized quickly it wasn't as dangerous a situation as it seems at first glance. Just inconvenient to the few who run into it more then anything. But the ambulance chasing lawyers smelled blood during the 1.5Tb issue and forced management into a hole.
Just remember, everything dies
:)
I sincerely smile in relief every time I hear someone other then myself say that phrase. It's a sign of someone who truely 'gets it' as far as hardware is concerned.
Thing is, I know Seagate really does try to push for high manufacturing standards (for example, did you know that every last Refurb drive *must* go through the full new-drive qualification before it's sent out? - something only a percentage of actual new drives have to go through because it's time consuming).
But WD and Hitachi and most other HDD companies have only slightly worse failure rates, negligible difference in failures really in the grand scheme of things. No matter if you go with WD, Seagate, Hitachi, IBM.... whatever. If there isn't an outstanding issue, then you're really looking at about the same chance of failure no matter which you buy.
The real decision is more 'how easy will it be to replace this if it fails?'
Funny though, I have in my system a 250Gb WD drive, that used to be in an external enclosure, until the USB interface controller died and I ripped the drive out - and now, after about a year of use, the internal drive's starting to fail... I rolled the crapshoot on this drive it seems.
(sorry for the bad formatting or lack thereof. I forgot to put it to 'Plain Old Text' when typing up the comment)
I'll answer your questions to the best of my ability, and as honestly as I can! I'm no statistician, but the 'drive becoming inaccessable at boot-up' is pretty much a very slim chance - but when you have 10 million drives in the field, it does happen. The conditions have to be just right - you have to reboot just after the drive writes the 320th log file to the firmware space of the drive. this is a log file that's written only occasionally, usually when there are bad sectors, missed writes, etc... might happen every few days on a computer in a nin-RAID home use situation.. and if that log file is written even one time after the magic #320, it rolls over the oldest file kept on the drive and there's no issue. It'll only stop responding IF the drive is powered up with log file #320 being the latest one written... a perfect storm situation. IF this is the case, then seagate is trying to put in place a procedure where you can simply ship them the drive, they hook it up to a serial controller, and re-flashed with the fixed firmware. That's all it takes to restore the drive to operation! As for buying new drives, that's up to you. None of the CC firmware drives were affected - only the SD firmware drives. I'd wait until later in the week, maybe next week, until they have a known working and properly proven firmware update. If you were to have flashed the drives with the 'bad' firmware - it would disable any read/write functions to the drive, but the drive would still be accessible in BIOS and a very good chance that flashing it back to a previous SD formware (or up to the yet to be released proven firmware) would make it all better. Oh, and RAID0 scares me by it's very nature... not an 'if' but 'when' the RAID 0 craps out and all data is lost - but I'm a bit jaded from too much tech support! :)