Jam*_*s T 24 hard-drive smart statistics
首先，我想每个人都知道硬盘驱动器出现故障的次数比制造商愿意承认的要多得多。谷歌做了一项研究，表明硬盘驱动器的 SMART 状态报告的某些原始数据属性可能与驱动器未来的故障有很强的相关性。
例如，我们发现，在第一次扫描错误后，驱动器在 60 天内发生故障的可能性是没有此类错误的驱动器的 39 倍。重新分配、离线重新分配和试用计数中的第一个错误也与更高的故障概率密切相关。尽管存在这些强相关性，我们发现仅基于 SMART 参数的故障预测模型的预测准确性可能会受到严重限制，因为我们的大部分故障驱动器都没有显示出任何 SMART 错误信号。
希捷似乎试图掩盖有关其驱动器的这些信息，声称只有他们的软件才能准确确定其驱动器的准确状态，而且他们的软件不会告诉您 SMART 属性的原始数据值。据我所知，Western Digital 没有做出这样的声明，但他们的状态报告工具似乎也没有报告原始数据值。
我一直在使用 smartmontools 的 HDtune 和 smartctl 来收集每个属性的原始数据值。我发现确实如此......当涉及到某些属性时，我将苹果与橙子进行了比较。例如，我发现大多数希捷硬盘会报告它们有数百万个读取错误，而西部数据 99% 的时间显示读取错误为 0。我还发现希捷会报告数百万个搜索错误，而西部数据似乎总是报告 0。
问：如何标准化这些数据？希捷是否会产生数百万个错误，而西部数据则没有产生任何错误？维基百科关于SMART状态的文章说制造商有不同的报告这些数据的方式。
这是我的假设：
我想我找到了一种方法来规范化（这是正确的术语吗？）数据。
希捷硬盘有一个西部数据硬盘没有的附加属性（硬件 ECC 恢复）。当您从 ECC 恢复计数中减去读取错误计数时，您可能会得到 0。这似乎相当于 Western Digital 报告的“读取错误”计数。这意味着 Western Digital 只报告它无法纠正的读取错误，而 Seagate 会计算所有读取错误并告诉您它能够修复的错误数量。
我有一个 Seagate 驱动器，其中读取错误计数小于 ECC 恢复计数，我注意到我的许多文件都已损坏。这就是我提出我的假设的方式。希捷产生的数以百万计的搜索错误对我来说仍然是个谜。
如果您有其他信息，请确认或更正我的假设。
这是我的西部数字驱动器的智能状态，以便您了解我在说什么：
james@ubuntu:~$ sudo smartctl -a /dev/sda
smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: WDC WD1001FALS-00E3A0
Serial Number: WD-WCATR0258512
Firmware Version: 05.01D05
User Capacity: 1,000,204,886,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Thu Jun 10 19:52:28 2010 PDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 179 175 021 Pre-fail Always - 4033
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 270
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1468
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 262
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 46
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 223
194 Temperature_Celsius 0x0022 105 102 000 Old_age Always - 42
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
编辑：这是我所说的导致数据损坏的希捷驱动器。此数据来自 HDTune。
HD Tune: ST3250623A Health
ID Current Worst ThresholdData Status
(01) Raw Read Error Rate 45 38 6 77882492 Ok
(03) Spin Up Time 99 98 0 0 Ok
(04) Start/Stop Count 100 100 20 640 Ok
(05) Reallocated Sector Count 100 100 36 0 Ok
(07) Seek Error Rate 85 60 30 359872048 Ok
(09) Power On Hours Count 94 94 0 6028 Ok
(0A) Spin Retry Count 100 100 97 0 Ok
(0C) Power Cycle Count 100 100 20 689 Ok
(C2) Temperature 25 55 0 25 Ok
(C3) Hardware ECC Recovered 50 47 0 201555081 Ok
(C5) Current Pending Sector 100 100 0 0 Ok
(C6) Offline Uncorrectable 100 100 0 0 Ok
(C7) Ultra DMA CRC Error Count 200 199 0 1 Ok
(C8) Write Error Rate 100 253 0 0 Ok
(CA) TA Counter Increased 100 253 0 0 Ok
Power On Time : 6028
Health Status : Ok
在我看来，恢复的硬件 ECC 大于原始读取错误率的事实是违反直觉的。
这是我发现的“正常”希捷驱动器，其中恢复的 ECC 与原始读取错误率匹配：
HD Tune: ST380011A Health
ID Current Worst ThresholdData Status
(01) Raw Read Error Rate 62 46 6 79986164 Ok
(03) Spin Up Time 98 98 0 0 Ok
(04) Start/Stop Count 100 100 20 6 Ok
(05) Reallocated Sector Count 100 100 36 0 Ok
(07) Seek Error Rate 83 60 30 210309663 Ok
(09) Power On Hours Count 93 93 0 6516 Ok
(0A) Spin Retry Count 100 100 97 0 Ok
(0C) Power Cycle Count 99 99 20 1325 Ok
(C2) Temperature 25 52 0 25 Ok
(C3) Hardware ECC Recovered 62 46 0 79986164 Ok
(C5) Current Pending Sector 100 100 0 0 Ok
(C6) Offline Uncorrectable 100 100 0 0 Ok
(C7) Ultra DMA CRC Error Count 200 188 0 18 Ok
(C8) Write Error Rate 100 253 0 0 Ok
(CA) TA Counter Increased 100 253 0 0 Ok
Power On Time : 6516
Health Status : Ok
编辑：
我想澄清一下，我知道 Google 通常认为 SMART 没有用。我知道每个人都应该备份他们的数据。然而，我从事修理其他人的电脑的业务。大多数人没有备份或 RAID。公司对硬盘进行故障排除并不划算，所以他们只是在 RAID 上运行它们直到它们死亡。我发现在我的工作中检查硬盘驱动器的 SMART 状态很有用。大约需要 30 秒。如果我足够幸运，一个坏驱动器显示出故障的迹象，例如扫描错误或重新分配扇区，我知道要让驱动器离开那里。如果没有这样的提示存在，我可能会花很多时间来解决速度缓慢和数据损坏的问题，直到我最终发现硬盘坏了。
我只是想微调这个过程。
sml*_*sml 15
好吧，首先我不同意你的前提。
谷歌做了一项研究，表明硬盘驱动器的 SMART 状态报告的某些原始数据属性可能与驱动器未来的故障有很强的相关性。
事实上，他们发现了相反的情况：
...我们发现仅基于 SMART 参数的故障预测模型的预测准确性可能会受到严重限制，因为我们的大部分故障驱动器都没有显示任何 SMART 错误信号。
其次，SMART 阈值没有标准化。驱动器本身的固件会将一个属性标记为“故障前”，但原始值对用户来说毫无意义。例如，希捷说：
正在根据某些阈值限制监视和测量各种属性。如果任何一个属性超过阈值，则一般 SMART 状态测试将从通过变为失败。
第三方 SMART 软件可能读取的 SMART 值并不基于这些值在 Seagate 硬盘驱动器中的使用方式。Seagate 不为声称读取单个 SMART 属性和阈值的软件程序提供支持。旧驱动器上可能有一些历史正确性，但新驱动器无疑将包含更新的解决方案、属性和阈值。
原始 SMART 值几乎没有意义，因为不同的制造商以不同的方式使用它们并且具有不同的阈值等。驱动器固件本身会告诉您何时处于“故障前”......或者可能没有，SMART 真的不是非常可靠。
定期备份！
Jef*_*ood 14
似乎不同的制造商有时将 SMART 值用于完全不同的事物，正如您在此处看到的：
我的 ReadyNAS 硬盘报告 SMART Raw Read Error Rate、Seek Error Rate 和 Hardware ECC Recovered 很高。我该怎么办？
Seagate 使用这些 SMART 字段进行内部计数，因此这是 Seagate 磁盘的已知问题。在其他字段中查找异常计数，尤其是重新分配的扇区 Ct 和 ATA 错误计数。
所以当谈到你的实际问题时......
如果我足够幸运，一个坏驱动器显示出故障的迹象，例如扫描错误或重新分配扇区，我知道要让驱动器离开那里。如果没有这样的提示存在，我可能会花很多时间来解决速度缓慢和数据损坏的问题，直到我最终发现硬盘坏了。
我想说一个很好的经验法则是，您只能期望 SMART 设置在同一驱动器制造商内具有可比性，甚至可能是同一驱动器型号！
因此，当您在考虑诊断那些 SMART 计数时，请记住这一点……一个制造商的“读取错误重试计数”可能与其他制造商的含义完全不同。悲伤但真实。:(
| 归档时间： |
|
| 查看次数： |
17646 次 |
| 最近记录： |