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. Advertising

  2. Sir To You

    Richard Guest

    Sir To You wrote:
    > 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.
    Richard, Jan 15, 2009
    #2
    1. Advertising

  3. On Thu, 15 Jan 2009 14:13:25 +1300, Richard <> wrote:

    >Sir To You wrote:
    >> 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.
    Stephen Worthington, Jan 15, 2009
    #3
  4. In message <>, Stephen Worthington
    wrote:

    > The main reported problem is that if you issue a flush cache command, it
    > takes over 30 s to respond ...


    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. On Thu, 15 Jan 2009 22:45:44 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <>, Stephen Worthington
    >wrote:
    >
    >> The main reported problem is that if you issue a flush cache command, it
    >> takes over 30 s to respond ...

    >
    >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.
    Stephen Worthington, Jan 15, 2009
    #5
  6. Sir To You

    Squiggle Guest

    Richard wrote:
    > Sir To You wrote:
    >> 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.
    >


    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. In message <>, Stephen Worthington
    wrote:

    > On Thu, 15 Jan 2009 22:45:44 +1300, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >>In message <>, Stephen
    >>Worthington wrote:
    >>
    >>> The main reported problem is that if you issue a flush cache command, it
    >>> takes over 30 s to respond ...

    >>
    >>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.


    Precisely.

    > 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.


    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

    Stephen Worthington wrote:
    > On Thu, 15 Jan 2009 14:13:25 +1300, Richard <> wrote:
    >
    >> Sir To You wrote:
    >>> 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.


    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

    On Jan 15, 11:49 pm, Stephen Worthington
    <34.nz56.remove_numbers> wrote:
    > On Thu, 15 Jan 2009 22:45:44 +1300, Lawrence D'Oliveiro
    > >Having cache on a hard drive is a stupid idea.


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

    > >It's putting RAM on the wrong side of a slow interface.


    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.

    >
    > 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.


    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?

    --
    Cheers
    Anton
    AD., Jan 16, 2009
    #9
  10. In message
    <>, AD.
    wrote:

    > On Jan 15, 11:49 pm, Stephen Worthington
    > <34.nz56.remove_numbers> wrote:


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

    >> On Thu, 15 Jan 2009 22:45:44 +1300, Lawrence D'Oliveiro
    >>
    >>> Having cache on a hard drive is a stupid idea. It's putting RAM on the
    >>> wrong side of a slow interface.

    >
    > How so? The speed of the SATA2 bus and disk cache far outstrip the
    > disks speed.


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

    > That's the opposite effect of putting your RAM on a slower interface.


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

    >> 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.

    >
    > 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.


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

    > 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.


    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
    <http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/>.

    > 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.


    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:
    > Stephen Worthington wrote:
    >> On Thu, 15 Jan 2009 14:13:25 +1300, Richard <> wrote:
    >>
    >>> Sir To You wrote:
    >>>> 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.

    >
    > 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.


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

    AD. Guest

    On Jan 16, 4:05 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message
    > <>, AD.
    > wrote:
    > > 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.

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


    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.

    > 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-o...>,
    > <http://www.theinquirer.net/inquirer/news/056/1009056/microsoft-discus...>.
    > That's why Linux gives you a choice of I/O schedulers
    > <http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-...>.


    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?


    > > 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.

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


    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.

    --
    Cheers
    Anton
    AD., Jan 16, 2009
    #12
  13. In message
    <>, AD.
    wrote:

    > On Jan 16, 4:05 pm, Lawrence D'Oliveiro <l...@geek-
    > central.gen.new_zealand> wrote:
    >
    >> In message
    >> <>, AD.
    >> wrote:
    >>
    >>> 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.

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

    >
    > 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.


    Which is not what the performance issue is about.

    > 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.


    Which is not what the performance issue is about.

    >> 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-o...>,
    >>

    <http://www.theinquirer.net/inquirer/news/056/1009056/microsoft-discus...>.
    >> That's why Linux gives you a choice of I/O schedulers
    >>

    <http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-...>.
    >
    > 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.


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

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


    But it doesn't.

    > Should the OS be in charge of wear leveling etc too?


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

    >>> 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.

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

    >
    > 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?


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

    > 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.


    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. On Fri, 16 Jan 2009 16:32:02 +1300, "~misfit~"
    <> wrote:

    >Somewhere on teh intarwebs "Richard" typed:
    >> Stephen Worthington wrote:
    >>> On Thu, 15 Jan 2009 14:13:25 +1300, Richard <> wrote:
    >>>
    >>>> Sir To You wrote:
    >>>>> 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.

    >>
    >> 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.

    >
    >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. :-(


    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

    Guest

    On Jan 15, 11:49 pm, Stephen Worthington
    <34.nz56.remove_numbers> wrote:
    > On Thu, 15 Jan 2009 22:45:44 +1300, Lawrence D'Oliveiro
    >
    > <_zealand> wrote:
    > >In message <>, Stephen Worthington
    > >wrote:

    >
    > >> The main reported problem is that if you issue a flush cache command, it
    > >> takes over 30 s to respond ...

    >
    > >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.


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

    AD. Guest

    On Jan 16, 6:51 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message
    > <>, AD.
    > wrote:
    > > 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.

    >
    > Which is not what the performance issue is about.


    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.

    > > 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.

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


    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.

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

    >
    > But it doesn't.


    Well those cheap ones didn't. Others do.

    >
    > > Should the OS be in charge of wear leveling etc too?

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


    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?

    >
    > >>> 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.

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

    >
    > > 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?

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


    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.

    >
    > > 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.

    >
    > 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.


    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.

    --
    Cheers
    Anton
    AD., Jan 16, 2009
    #16
  17. Sir To You

    ~misfit~ Guest

    Somewhere on teh intarwebs "Stephen Worthington" typed:
    > On Fri, 16 Jan 2009 16:32:02 +1300, "~misfit~"
    > <> wrote:
    >
    >> Somewhere on teh intarwebs "Richard" typed:
    >>> Stephen Worthington wrote:
    >>>> On Thu, 15 Jan 2009 14:13:25 +1300, Richard <>
    >>>> wrote:
    >>>>
    >>>>> Sir To You wrote:
    >>>>>> 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.
    >>>
    >>> 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.

    >>
    >> 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. :-(

    >
    > 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.


    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.

    > You could
    > write a little script to poke the drive every so often.


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

    > 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.


    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.

    > 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.


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

    EMB Guest

    Sir To You wrote:
    > 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.


    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. On Mon, 19 Jan 2009 22:16:10 +1300, EMB <> wrote:

    >Sir To You wrote:
    >> 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.

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

    Squiggle Guest

    Stephen Worthington wrote:
    > On Mon, 19 Jan 2009 22:16:10 +1300, EMB <> wrote:
    >
    >> Sir To You wrote:
    >>> 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.

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

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Silverstrand

    HEXUS.reviews :: LaCie Two Big 1TB DAS enclosure

    Silverstrand, Sep 28, 2006, in forum: Front Page News
    Replies:
    0
    Views:
    670
    Silverstrand
    Sep 28, 2006
  2. Ian
    Replies:
    0
    Views:
    1,154
  3. Smart Shoppers

    Seagate 1TB Hard Disk Related Products

    Smart Shoppers, Oct 8, 2009, in forum: NZ Computing
    Replies:
    0
    Views:
    400
    Smart Shoppers
    Oct 8, 2009
  4. Becky
    Replies:
    0
    Views:
    768
    Becky
    Dec 7, 2012
  5. Sandman

    1TB external bus-powered SSD drive with Thunderbolt?

    Sandman, May 30, 2014, in forum: Digital Photography
    Replies:
    157
    Views:
    1,011
    Sandman
    Jun 6, 2014
Loading...

Share This Page