NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

intothevoid's avatar
intothevoid
Aspirant
Oct 01, 2012

[Solved] Seagate ST3000DM001-9YN166: Load Cycle Count

Hi,

sorry if this has been discussed already, all i could find are topics about upgrading the firmware on these drives.

I've got a NV+v2 with 4 3TB ST3000DM001-9YN166 disks in it, firmware CCH4 (the latest).
System has been running for a couple of months now, and all was working smoothly until i got a warning 2 weeks ago:

Detected increasing command timeouts[65537] on disk 1 [ST3000DM001-9YN166, W1F083HJ]. This often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy.


Looking into the SMART status, it indeed gives some ridiculously high number (4295032833) on command time out for disk 1. On the other 3 disks it's 0.
Another thing i noticed in the SMART status for all disks though, is that the load count cycle is quite high: around 43000 after 1800 power on hours.
After a bit of googling however, all i could find was this problem cropping up on WD green drives. The solution seems to be to set the idle time a bit higher.
I did find this old topic (http://www.readynas.com/forum/viewtopic.php?f=36&t=51536) explaining how to do it on some other seagate model, but i wanted to get some feedback before i attempt to change things via ssh. Don't wanna corrupt anything.
So basically my questions are:

1) Is the command time out problem in anyway related to the lcc problem, or is this drive just about to die no matter what?
2) Does anybody else have these high lcc numbers with the ST3000DM001 drives?
3) Is it worthwhile changing the idle time setting with hdparm?
3b) If yes, are the instructions in that old topic still valid?

On a related note, i did install the ssh add-on and looked around a little, however when i try to get drive status with hdparm i get this:
root@nas:~# hdparm -i /dev/sda

/dev/sda:
HDIO_GET_IDENTITY failed: Inappropriate ioctl for device


Same for sdb, sdc, and sdd
Am i using the right identifiers here? Sorry for the ignorance :oops:

Hope this isn't all too confusing, i tried to cram a lot of information in this post :-)
Thanks in advance for any help!

EDIT: apparently i do not have permission to use the url tag..

50 Replies

Replies have been turned off for this discussion
  • Cynan - good info, that makes me feel a little better, but I stress the "little"! :)
  • seems a little strange,

    binary 100010001 is 111 in hex
    hex 4295032833 is 100001010010101000000110010100000110011 in binary

    or am i doing something wrong? :-)
  • intothevoid wrote:
    seems a little strange,

    binary 100010001 is 111 in hex
    hex 4295032833 is 100001010010101000000110010100000110011 in binary

    or am i doing something wrong? :-)


    4295032833 is a decimal number. Convert it to hex. You treated it like a hex number.
  • Btw I think that many timeouts would take centuries. So either seagate has a fw bug or the readynas is not polling the smart info correctly. Does the drive show this smart data in a different system? If so then its seagates problem I would think. However netgear could give provide an option to not treat this as a failed drive to work around the bug.
  • StephenB's avatar
    StephenB
    Guru - Experienced User
    dsm1212 wrote:
    Btw I think that many timeouts would take centuries. So either seagate has a fw bug or the readynas is not polling the smart info correctly. Does the drive show this smart data in a different system? If so then its seagates problem I would think. However netgear could give provide an option to not treat this as a failed drive to work around the bug.


    Based on the limited information available, it appears that with this drive Seagate is formatting this parameter in a proprietary way - packing multiple counts into the same parameter. Hence the 0x100010001 or 0x700070007 or 0xE000E000E values that have been reported here. Exactly why they are doing this is unknown - perhaps it is simply a firmware bug in the drive, or perhaps the three subfields are somewhat different (and can hold different values in some failure modes). Since these counts have been confirmed by some users on a PC (using other SMART query tools), that doesn't seem to be a ReadyNAS issue.

    But there some other users who are getting alerts on this parameter, but are seeing 0 in the SMART parameter. That seems more likely to be a ReadyNAS bug.
  • I have two ST3000DM001-1CH166 in my Ultra4, and I am getting:

    Detected increasing uncorrectable errors
    Detected increasing pending sector count

    On Disk 1, and a couple of days later the NAS considered the disk dead. When I test it with Seatools on a PC everything is 100% healthy. Nothing found at all.

    Starting to wonder if this is related to this thread... even though it is a slightly different model drive and NAS.
  • Hi all,

    a quick follow up:

    After my last post in this thread, 3 months ago, I decided to try one final thing: I disabled the 'disk spin-down after X minutes of inactivity' power setting. Annnnd: no problems ever since! All disks are fine and have stopped failing.
    I waited a while before posting this since the original problem occurred only about once a month, but I think after 3 months we can conclude that this fixes things :-)
  • grr wrote:
    I have two ST3000DM001-1CH166 in my Ultra4, and I am getting:

    Detected increasing uncorrectable errors
    Detected increasing pending sector count

    On Disk 1, and a couple of days later the NAS considered the disk dead. When I test it with Seatools on a PC everything is 100% healthy. Nothing found at all.

    Starting to wonder if this is related to this thread... even though it is a slightly different model drive and NAS.


    I have started having this same problem on my NAS 314 - OS 6.1.7.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Thu May 8 2014 22:57:40
    Disk: Detected increasing uncorrectable error count: [1592] on disk 3 (Internal) [ST3000DM001-1CH166, Z1F3910G]. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy.
    Thu May 8 2014 22:57:34
    Disk: Detected increasing pending sector count: [1592] on disk 3 (Internal) [ST3000DM001-1CH166, Z1F3910G] 37 times in the past 30 days. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy.
    Thu May 8 2014 22:55:39
    Disk: Detected increasing ATA error count: [87] on disk 3 (Internal) [ST3000DM001-1CH166, Z1F3910G] 12 times in the past 30 days. This condition often indicates an impending failure. Please be prepared to replace this disk to maintain data redundancy.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    What ended up happening in the end? Did you just buy a new disk and replace it?
  • StephenB's avatar
    StephenB
    Guru - Experienced User
    I suggest testing the disk with seatools in a PC. If you have 1592 pending sectors, the disk should fail the diagnostic.

    If you can't run seatools, RMA the disk anyway. There is a code for that in the RMA template Seagate uses.

    (BTW, if the disk is new, you are better off exchanging it with the seller, as Seagate will not give you a new disk in return. If you do end up RMAing, look for an option to send you the new disk before you return the defective one. In the US that costs almost the same as shipping the disk yourself, and you get the replacement disk a lot faster).

NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology! 

Join Us!

ProSupport for Business

Comprehensive support plans for maximum network uptime and business peace of mind.

 

Learn More