SMART 显示高 Load_Cycle_Count |为什么以及如何防止数量增加?

SMART 显示高 Load_Cycle_Count |为什么以及如何防止数量增加?

我刚刚意识到我的一些硬盘有巨大的 Load_Cycle_Count当读出他们的 SMART 数据时。有些人很快就会失败,我问自己为什么会这样,以及我是否可以做些什么来防止他们死亡。

alex@ga-P55A-UD5:~$ sudo smartctl -a /dev/sdb
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic](本地构建)
版权所有 (C) 2002-16,Bruce Allen、Christian Franke,www.smartmontools.org

=== 信息部分开始 ===
型号系列:西部数据鱼子酱绿 (AF)
设备型号:WDC WD10EARS-00Y5B1
[...]
具有阈值的供应商特定 SMART 属性:
ID# ATTRIBUTE_NAME 标志值 最差阈值类型已更新 WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count 0x0032 090 090 000 Old_age 始终 - 10281
  9 Power_On_Hours 0x0032 062 062 000 Old_age 始终 - 28456
193 Load_Cycle_Count 0x0032 001 001 000 Old_age 始终 - 611460
alex@ga-P55A-UD5:~$ sudo smartctl -a /dev/sdc
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic](本地构建)
版权所有 (C) 2002-16,Bruce Allen、Christian Franke,www.smartmontools.org

=== 信息部分开始 ===
型号系列:西部数据鱼子绿
设备型号:WDC WD6400AADS-00M2B0
[...]
具有阈值的供应商特定 SMART 属性:
ID# ATTRIBUTE_NAME 标志值 最差阈值类型已更新 WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count 0x0032 093 093 000 Old_age 始终 - 7615
  9 Power_On_Hours 0x0032 057 057 000 Old_age 始终 - 31743
193 Load_Cycle_Count 0x0032 053 053 000 Old_age 始终 - 442121
alex@silent-ssd:~$ sudo smartctl -a /dev/sdd
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-142-generic](本地构建)
版权所有 (C) 2002-16,Bruce Allen、Christian Franke,www.smartmontools.org

=== 信息部分开始 ===
型号系列:西部数据绿色
设备型号:WDC WD20EARX-00PASB0
[...]
具有阈值的供应商特定 SMART 属性:
ID# ATTRIBUTE_NAME 标志值 最差阈值类型已更新 WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x002f 200 200 051 预失败始终 - 0
  4 Start_Stop_Count 0x0032 098 098 000 Old_age 始终 - 2477
  9 Power_On_Hours 0x0032 085 085 000 Old_age 始终 - 11176
193 Load_Cycle_Count 0x0032 181 181 000 Old_age 始终 - 59646

答案1

到目前为止我的发现:

原因

  • 关于西部数据以及各种网站1,2,3,4,5,6 高数字在 SMART 属性 193 Load_Cycle_Count 中WesternDigital 推出的一项名为智能公园
  • Intellipark 在他们的一些硬盘型号中实施,特别是在他们的绿色系列中。
  • 它旨在减少不使用驱动器时的功耗。
  • 在某些用例中,特别是与 Linux 操作系统结合使用时,此 intellipark 功能往往会缩短硬盘的寿命。

解决方案

  • 西部数据解释说这不是他们的功能错误,而是配置错误的操作系统,他们给出了一些关于如何正确配置 Linux 的建议
  • 西部数据还发布了DOS工具修改某些设备上的 intellipark-feature。
  • 针对 Linux 平台的 Christophe Bothamy 发布闲置3工具修改该 intellipark-feature- 非常感谢我的网站。
  • 正如下面的评论中提到的,hdparm -J是否修改 wd IDLE3 计时器,但正如另一条评论指出的那样:这个实现并不像官方的WDIDLE3.EXE那么彻底

我做了什么

现在我下载idle3ctl并完全关闭了intellipark。希望这将有助于防止磁盘快速发生故障。但无论如何,至少有一个磁盘几乎已失效,就 SMART 而言

要禁用 intellipark 功能,我遵循了闲置3工具指示。

首先我读出这个intellipark功能的idle3计时器值:sudo ./idle3ctl -g /dev/sdx

比我禁用计时器 sudo ./idle3ctl -d /dev/sdx

需要关闭/开启电源周期才能生效 sudo hdparm -Y /dev/sdx

之后我重新检查了idle3时间并在重新启动后执行了相同的操作:

alex@silent-ssd:~/idle3tools/idle3-tools-0.9.1$ sudo ./idle3ctl -g /dev/sdd
Idle3 定时器被禁用

编辑2023

我只是想提供有关驱动器使用 4 年后的状态的更新信息。到目前为止,所有驱动器仍然处于活动状态,但负载周期计数超过 500.000 的两个磁盘不再使用,或者至少只是偶尔用于不重要的事情。第三个驱动器仍在使用中。它持有 BTC 区块链,四年来几乎 24/7 运行。负载循环计数的数量仅增加了几千。对于降速,我使用 hd-idle 和 3 小时的计时器,但由于几乎永久更新的区块链,该计时器通常不会生效。

这是该驱动器的智能数据:

=== 信息部分开始 ===
型号系列:西部数据绿色
设备型号:WDC WD20EARX-00PASB0
[...]

SMART 属性数据结构修订号:16
具有阈值的供应商特定 SMART 属性:
ID# ATTRIBUTE_NAME 标志值 最差阈值类型已更新 WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x002f 200 200 051 预失败始终 - 0
  4 Start_Stop_Count 0x0032 098 098 000 Old_age 始终 - 2713
  9 Power_On_Hours 0x0032 046 046 000 Old_age 始终 - 40109
 193 Load_Cycle_Count 0x0032 180 180 000 Old_age 始终 - 61955
作为有关 HDD 使用寿命的主题的旁注:
感谢这篇文章(https://superuser.com/questions/197862/how-harmful-is-a-hard-disk-spin-cycle)我找到了一篇不错的论文/研究(https://www.usenix.org) /legacy/event/fast07/tech/full_papers/pinheiro/pinheiro_html/index.html )有关硬盘驱动器故障及其关于如何解释 SMART 值的结论。

答案2

我有一个 1TB WD Blue Mobile WD10SPZX,LCC 额定耐用度为 600k。它的增长速度也很快(每小时大约 7.7 个周期):

coutinho@discovery:~$ sudo smartctl -a /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-13-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD10SPZX-75Z10T1
[...]
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       119
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       3040
193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       23541

我尝试了两个 WDWDIDLE3DOS 工具和闲置3工具,没有一个适用于我的磁盘。

最后,我通过使用 hdparm 将 APM 值设置为 254,将以下几行添加到 /etc/hdparm.conf,成功地将 LCC 的增量降低到每小时 1 以下:

/dev/sdb {
    apm           = 254
    spindown_time = 0
}

答案3

WD Green 磁盘设计为在磁盘闲置后相对较快地停放磁头。因此,您将获得较高的负载计数。

老文章了,不过还是很准确的https://www.pugetsystems.com/labs/articles/Western-Digital-Green-vs-Red-Hard-Drives-602/

加载/卸载周期是指磁盘旋转盘片以准备操作的时间。通常,当您打开系统、从待机状态恢复或驱动器闲置时间足够长以至于操作系统关闭驱动器时,就会发生这种情况。 [..] 绿色驱动器额定的 300,000 次循环确实已经相当多了。即使您打开/关闭系统或让它闲置足够长的时间以关闭驱动器电源,一年 365 天每天 20 次,绿色驱动器仍应可持续使用 40 年以上。

机头停车延时8秒

在您的情况下,您的两个磁盘已分别通电 31743 小时和 11176 小时(大约 3 年 6 个月和 1 年 3 个月,24x7)。在这段时间里,卸载/加载周期的数量确实不是不合理的。

如果您每周 7 天、每天 24 小时运行,请注意,您应该使用 WD 红色而不是绿色。

答案4

添加到讨论:我监督一台 Synology NAS,它有 5 个驱动器,并装有 WD Red 3TB 驱动器

  • 驱动器 1、2、3 和 5 的 Power_On_Hours = 49760, +/- 2。
  • 驱动器 4 的 Power_On_Hours = 26959,因为它在某个时刻更换了故障驱动器。

替换件是最初购买的 8 个驱动器批次之一,其中 5 个已安装,3 个保存为替换件。因此,所有驱动器都来自同一时间点,尽管是从两个不同的供应商购买的,以避免从一批中获得所有驱动器。

  • 驱动器 1,3 和 5 的 Load_Cycle_Count = 345 +/-2
  • 驱动器 2 Load_Cycle_Count = 656
  • 驱动器 4(只有 27k 小时的驱动器)Load_Cycle_Count = 93144 !!

无论如何,我正在查看 SMART 数据,因为有关驱动器 2 的错误警告电子邮件,

  • 驱动器 2:Raw_Read_Error_Rate = 4520。
  • 驱动器 1,3,5 Raw_Read_Error_Rate = 0
  • 驱动器 4(同样是 27khr 单元)Raw_Read_Error_Rate = 10232 !!

因此,由于某种原因,比其他驱动器安装晚的一个驱动器具有巨大的 Load_Cycle_Count 和 Raw_Read_Error_Rate。

不知道该怎么理解这一切。

相关内容