Seagate 1TB drive problems

Discussion in 'NZ Computing' started by Sir To You, Jan 15, 2009.

  1. Sir To You

    Sir To You Guest

    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.
     
    Sir To You, Jan 15, 2009
    #1
    1. Advertisements

  2. Sir To You

    Richard Guest

    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.
     
    Richard, Jan 15, 2009
    #2
    1. Advertisements

  3. 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.
     
    Stephen Worthington, Jan 15, 2009
    #3
  4. Having cache on a hard drive is a stupid idea. It's putting RAM on the wrong
    side of a slow interface.
     
    Lawrence D'Oliveiro, Jan 15, 2009
    #4
  5. 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.
     
    Stephen Worthington, Jan 15, 2009
    #5
  6. Sir To You

    Squiggle Guest

    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?
     
    Squiggle, Jan 15, 2009
    #6
  7. I'd be surprised if you noticed any difference under a reasonably-written
    operating system.
     
    Lawrence D'Oliveiro, Jan 15, 2009
    #7
  8. Sir To You

    Richard Guest

    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.
     
    Richard, Jan 16, 2009
    #8
  9. Sir To You

    AD. Guest

    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?
     
    AD., Jan 16, 2009
    #9
  10. 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.
     
    Lawrence D'Oliveiro, Jan 16, 2009
    #10
  11. Sir To You

    ~misfit~ Guest

    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. :-(
     
    ~misfit~, Jan 16, 2009
    #11
  12. Sir To You

    AD. Guest

    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.
     
    AD., Jan 16, 2009
    #12
  13. 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.
     
    Lawrence D'Oliveiro, Jan 16, 2009
    #13
  14. 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.
     
    Stephen Worthington, Jan 16, 2009
    #14
  15. Sir To You

    news2.thing Guest

    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
     
    news2.thing, Jan 16, 2009
    #15
  16. Sir To You

    AD. Guest

    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.
     
    AD., Jan 16, 2009
    #16
  17. Sir To You

    ~misfit~ Guest

    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,
     
    ~misfit~, Jan 16, 2009
    #17
  18. Sir To You

    EMB Guest

    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/
     
    EMB, Jan 19, 2009
    #18
  19. Stephen Worthington, Jan 19, 2009
    #19
  20. Sir To You

    Squiggle Guest

    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
     
    Squiggle, Jan 19, 2009
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.