Seagate 1TB drive problems

Be very careful if you have purchased a seagate 1tb 7200.11 drive
recently (model ST31000340AS). Many of these shipped with firmware
SD15 and they are having a very high failure rate.

It is a bios problem, which causes the drive to go into a permanent
busy state rendering it invisible to the BIOS. The only fix is to use
specialised equipment to reset the drive and the problem could still
reoccur.

I just bought 2 of these recently dammit. Basically I am not using
them for now as I cannot afford to lose my data.

Check seagate forums for more info - there are a lot of angry people
out there. Best case scenario is seagate will supply a firmware update
ASAP.

 

I had a 1 and a 1.5TB die within weeks of new.

Now running 1tb wd drives and they have being months without incident.

 

I have a 1 Tbyte (SD31000340AS) and a 500 Mbyte (SD3500320AS) both
running SD15. The 500 Mbyte is a replacement for one that died at
about 6 weeks. Both of these drives have been fine for months now
(SMART reported power on times of 264 days and 213 days respectively).
They are very fast drives - truly impressive performance compared to
the Seagate IDE drives I was using before then.

I also recently got a 1.5 Tbyte SD31500341AS, and its write speed is
less than one quarter of what it should be. So it is going back as
soon as its forward replacement arrives on Monday (they are out of
stock at the moment). It is running CC1G firmware, which is also
reported to have problems. The main reported problem is that if you
issue a flush cache command, it takes over 30 s to respond, and lots
of operating systems will timeout well before that. Let alone the
impact on performance of a 30 s delay. But that is not the problem I
am seeing, as far as I can tell. The read speed is fine, just like
the other two drives, but the write speed is terrible, like a DVD
writer instead of a new hard drive. It is possible that this is the
same problem if Vista SP1 is issuing cache flush commands for some
reason. Anyway, the replacement drive will be from a new shipment, so
I can hope it might have the newer CC1H firmware.

 

Having cache on a hard drive is a stupid idea. It's putting RAM on the wrong
side of a slow interface.

 

It allows the drive to reorganise the head movements to reduce how far
it has to move them, and to queue commands. Of course, the operating
system should already be doing that.

My practical experience says that drives with bigger on-board cache do
actually perform better, under Windows and OS/2. I can not say yet
for Linux.

 

Picked up the replacement for the 750GB 7200.11 that failed over the
xmas period yesterday, same firmware (SD15) so i'm not exactly
optimistic about it lasting. Plan to work it as hard as I can for the
next few weeks by repeatedly copying data from the other drive until its
full and reformatting and starting again. First sign of trouble and back
it goes to be replaced with a non-seagate/maxtor drive.

Has anybody in here been using the samsung spinpoint drives? What are
your thoughts on them?

 

I'd be surprised if you noticed any difference under a reasonably-written
operating system.

 

Could be what I was seeing - basically windows would declare the drive
dead often - disabling and reenabling the controller it was on would
bring them back for a while.

I even went and got a new PCI card because I thought it might have being
related to using a sata 150 controller on them, but it was no better.

They were fine for the initial copy of stuff over and for playing stuff
off, its only when I started wanting to organize things that they both
started acting up.

 

Yeah, another case where the armchair critic knows better than the
rest of the industry.

How so? The speed of the SATA2 bus and disk cache far outstrip the
disks speed. That's the opposite effect of putting your RAM on a
slower interface.

The thing is the OS doesn't really know enough about the low level
implementation details and geometry of the device to do that stuff any
more.

And I think that abstraction is a good thing. I'd rather keep the OS
interface simple (well simpler) and the CPU free from all those
optimisations as well as avoiding the potential for doing it
suboptimally or even plain wrong when new devices or device types (eg
solid state) come out. And with things like hardware raid controllers,
the OS would either be doing redundant work or needing to know too
much about the implementation of the raid device.

After all, if the drive manufacturer can occasionally get the firmware
wrong for a specific part they designed, what chance do the OS
developers have to do a consistently better job when dealing with many
many more devices?

 

In message

Can't figure out how to reply to the right message, can you?

But RAM is faster still. That's the point.

RAM should be accessible via the RAM interface. That's how to take advantage
of its speed.

Linux does <http://lwn.net/Articles/114770/>,

Like it or not, flash drives don't behave the same. This has already had an
effect on Windows performance
<http://www.theinquirer.net/inquirer/news/472/1033472/sandisk-delays-optimised-ssds>,
<http://www.theinquirer.net/inquirer/news/056/1009056/microsoft-discuss-ssds-windows>.
That's why Linux gives you a choice of I/O schedulers

Hard drives will soon be too big for RAID to cope.

 

Somewhere on teh intarwebs "Richard" typed:

Damn! This is worrying me now. I bought a 1.5TB to act as backup for all my
320GB / 200GB and a 500GB drives. I'm thinkinh now that maybe I shouldn't
just use it as I am, via USB when needed. Perhaps I should connect it to a
PC and run it for a couple months to get past the "infant mortality" period.
After all, it is my backup drive and I rushed to buy it before the warranty
period reduced. (Obviously anything that would be *really* disastrous to
lose is 'double-backed up'.)

Interesting thread.... Thanks. Might have to pull the E7300 out of my
desktop and fit the Celeron 420 (to save power, although there's little if
any difference in consumption at idle), then run it for a month. There goes
$40. :-(

 

Umm, it doesn't. Since LBA came about for IDE drives, the reported
disk geometry is a fictional construct. And I think SCSI always used
some sort of linear addressing anyway.

I don't have time for a proper search, but there are plenty of cites
of that in this thread:
https://kerneltrap.org/mailarchive/linux-kernel/2008/4/9/1386484/thread

The Linux I/O schedulers work at a higher level than physical disk
geometry. They are the OS level queues for balancing I/O requests from
different processes, not for matching I/O to disk geometry and disk
head positions which the drive firmware queue does.

Those links support my point - a new type of storage device comes
along without any optimisation in firmware, and lo and behold the OS
is suboptimal at accessing it. The OS isn't psychic - especially if it
is older than the device.

The drive firmware should handle that - after all it is the one that
knows how it works internally.

Should the OS be in charge of wear leveling etc too? Or should that
just be handled by the drives firmware?

So? You would throw away the ability of a specialist controller to
abstract away implementation details of the underlying drives because
one example of a controller type might not be relevant anymore?

In saying that RAID isn't going away anytime soon though - it may
become less and less useful in certain circumstances as time goes on,
but it will be around for some time yet.

 

In message

Which is not what the performance issue is about.

Which is not what the performance issue is about.

Strange. You were the one saying it shouldn't matter to the OS.

But it doesn't.

Yes. There are some Linux filesystems being developed to deal with that.

What other "specialist controller types" do you think are still relevant?

It'll start to fail pretty dramatically once hard drives get up to 10TB
capacity or so. At that point it'll be just about impossible to do a full
(re)build of a RAID container without hitting at least one I/O error.
That's pretty much fatal to RAID.

 

There definitely is infant mortality in Seagate drives at present. But
no-one knows if it is power on time on the electronics, rotational
time, or something else. My guess would be power on time, and if so,
then just leaving the drive on a USB port would be enough. You could
write a little script to poke the drive every so often. I doubt that
you need to put it on a SATA port on your desktop, as it is on a USB
to SATA converter in your external drive box, and the drive will not
be able to tell the difference.

As backup strategies go, using just one backup copy on one drive,
while better than nothing, is not exactly safe. Even if there was no
infant mortality problem, all you have to do is knock the external
drive box hard enough and the disk will die. A drop of the height of
a normal (vertical) desktop case onto carpet made my old 320 Gbyte IDE
drive start giving all sorts of SMART warnings that it was about to
fail. Backing up critical data (eg registration keys) to USB sticks
seems good, as you can normally have more than one and they are
reasonably robust. As are good quality DVDs, and you can have as many
of them as you like (< $0.70 each for quite reasonable quality). But
USB sticks and DVDs are not large enough to comfortably backup large
things (eg your TV and video files, or an installed Vista partition).
Backup to a huge hard disk has the advantage of being able to backup
absolutely everything (full drive images), and also of being very
fast. But the backup will be physically fragile as long as you are
using external drives (which you have to in order to do off-site
backups). I think that if you want to do hard disk backups, you need
at least two backup drives, and should use an external drive box like
the Vantec one that allows you to plug and unplug the drive at will.
That way, you can store the backup drives in proper shock resistant
packaging (such as what they are delivered in). And preferably you
should be using a third drive which is rotated off-site. Or at least
stored in the garage, instead of the house, so that a fire or burglary
in either is not going to get both.

 

They do for Linux....the value of cache depends on the
cost....Lawrence is being his usual "perfectionalist self"....he's
read some kernel memory theory/decusions and now belives it carte
blanche....

Except the real world is rarely perfect....

ie a small cache on the drive shows a performance boost, a bigger and
bigger cache show diminishing returns....in the real world....

"IF" you wanted to improve performance and have say have 1gb of cache,
letting the OS decide where to use that memory to overall improve the
performance of the application is usually the best way....however if
you have a motherboard ram limit of 8gb and get a cache controller
with 512mb.....its going to be faster than a machine with 8gb and no
cache on the controller, for disk i/o related work....wont make any
difference for memory intensive tasks...unless that includes a disk
intensive i/o at the same time....

regards

Thing



regards

Thing





regards

Thing

 

You brought up cache on a drive as being a stupid idea - that was the
statement I was objecting to. The cache (or more accurately a buffer)
on the drive is only involved with these low level tasks like read
ahead and write sequencing, and disabling those features does
measurably reduce performance.

So that is what the issue was about.

It shouldn't - if the device actually did any internal optimisation
like modern hard drives or the better engineered solid state drives
do.

Those links you provided were evidence of how things go bad when the
OS needs to know low level details about the devices to work well, and
how long it takes for software to catch up and handle them properly.

Well those cheap ones didn't. Others do.

So instead of the device handling it transparently in firmware,
peoples disks should wear out while the Linux devs work out how to
handle it best and then those changes eventually trickle down into the
stable distro versions after extensive testing etc?

And with that disadvantage, what advantage is there in bloating the OS
with this extra code?

Doesn't sound like the most efficient way of handling it to me. Surely
finite developer time is better spent on something other than chasing
and maintaining this stuff?

Who knows (RAID was the one current one that came to mind), I'm just
saying that if you throw out that abstraction and put the OS in charge
of all the low level detail you won't get any future classes of
controllers able to use it for any new purpose.

RAID 5 is looking shaky in that regard, and RAID 6 will get to that
point too. But RAID 10 and others aren't quite as susceptible as RAID
5/6 is as the whole array isn't hammered the same way for rebuilds.

But keep in mind that lots of array are built for speed (rather than
just for large filesystems) with much smaller SCSI/SAS drives than
what you get in consumer SATA disks. It will take far longer for SAS
drives (or their equivalent) to reach 10TB.

There is no obvious RAID replacement for fault tolerance on the
horizon. Sure you can cluster stuff at larger sites (and they would be
already), but that still leaves a large gap for smaller sites or
individual computers.

It will take some time before RAID is a thing of the past. Anyway that
tangent has gone well off topic.

 

Somewhere on teh intarwebs "Stephen Worthington" typed:

I thought about that. However I use (and like) Hard Disk Sentinel, which
tells me everything I want to know about the disk. HDS doesn't work over USB
(or my desktop's JMicron eSATA controller either, something I checked as I
considered a PC card to eSATA option, if only for the monitoring
capabilities). Therefore I'm unlikely to get much in the way of a warning if
the disk is terminal in the USB dock until it no longer works, a
less-than-ideal situation.

LOL, you say that like anyone could do it. (The drive does 'go to sleep' in
the dock after a period of inactivity.)

True. However, as mentioned, it would be for my own monitoring purposes.
While not catastrophic, a (1.5TB) drive failure with no warning would be
very inconvenient, likely losing me some downloaded files. I guess that,
since I discovered HDS I've been spoilt for real-time HD info, to the point
that I feel deprived without it.

Aye. As I mentioned above, critical data is "double backed up", at the least
present on two HDs, at the most several HDs (in more than one machine, as
well as external), on optical media at a mate's place and on USB flash
storage.

Cheers,

 

Looks like they have offered a firmware update and free data recovery.

http://www.theregister.co.uk/2009/01/18/barracuda_firmware_upgrade_and_recovery/

 

That is good news. I have 2 affected drives so far, and one more in
an external enclosure to check tomorrow. The 3 older drives in my
MythTV box have older (presumably non-buggy) firmware. Thanks for the
URL.

 

Don't get your hopes up just yet, downloaded and burnt the bootable CD,
confirmed the model number and firmware version are in the affected
list, tried to update the firmware and it failed with a SIGSEGV error.

On a ST3750330AS (750GB), SD15 firmware.

It appears that if the part number on the drive ends in -303 the update
does not work. Which is somewhat confusing when the screen mentions
-303 drives in the heading. It appears to be for -300 part numbers only.

http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=5133