jia*_*103 7 linux hard-drive smart
我即将获得几个全新的 HGST DeskStar 4TB 3.5" SATA 硬盘驱动器。在我开始使用它们并将我的数据委托给他们之前，这些天是否有任何推荐的做法我应该执行，特别是因为它们仍处于初始阶段保修期？
通常，我只是插入新驱动器，对它们进行 fdisk，在需要时进行加密，使用 ext4 进行格式化，然后继续使用，不过这次将是 ZFS（通过 ZoL）。当我有时间时，我会将它们连接到 smartmontools 以便 smartd 可以监视它们，但仅此而已。
我应该在开始时查看任何特定的 SMART 值吗？我是否应该在整个磁盘长度上写入 1、0 或随机数据，如果是，则将其全部读回？我应该让它通电整整 30 天并留意任何事情吗？我是否应该验证驱动器的 APM 设置已关闭，以便不会因频繁的减速而过早磨损？
2017 年 10 月 7 日更新：我遵循了@Xen2050 的回答和@sawdust 的评论中的建议。
我拿到了驱动器，我准备开始测试它们。我创建了一个脚本来捕获 Xen2050 的建议。
#!/bin/sh
AWK=/usr/bin/awk
CLEAR=/usr/bin/clear
GREP=/bin/grep
SLEEP=/bin/sleep
SMARTCTL=/usr/sbin/smartctl
EXIT_SUCCESS=0
EXIT_INSUFFICIENT_ARGS=1
usage() {
cat << END_OF_FILE
USAGE
${0} interval device
EXAMPLES
${0} /dev/sda
END_OF_FILE
}
runIteration() {
runIteration_device=${1}
#${HDPARM} -B ${runIteration_device} | ${GREP} 'APM_level'
#${HDDTEMP} ${runIteration_device}
#${SMARTCTL} --attributes ${runIteration_device}
${SMARTCTL} --attributes ${runIteration_device} | ${GREP} -E '(ATTRIBUTE_NAME|Temperature_Celsius|Current_Pending_Sector|Pre\-fail|Power_On_Hours|Power_Cycle_Count|Load_Cycle_Count)' | ${AWK} '
{
for (i = 1; i <= NF; ++i) {
len=20;
if ((i != 3) && (i != 7) && (i != 8)) {
s = substr($i, 0, len-1);
printf("%-4s", s);
}
if (i == 2) {
printf(sprintf("%s%0" (len-length(s)) "s", "", ""));
}
printf(" ");
}
print "";
}'
${SMARTCTL} --get=apm ${runIteration_device} | ${GREP} '^APM'
}
exitCode=${EXIT_SUCCESS}
if [ ${#} -eq 2 ]; then
interval=${1}
device=${2}
while [ 1 ]; do
${CLEAR}
runIteration ${device}
${SLEEP} ${interval}
done
else
exitCode=${EXIT_INSUFFICIENT_ARGS}
echo ${0}: Insufficient arguments 1>&2
usage 1>&2
fi
exit ${exitCode}
我的四个新驱动器中的两个同时插入了两个 USB 扩展坞，这些驱动器放在桌子上只是因为这台计算机没有可用的 SATA 端口。我不确定我是否应该期望温度高于或低于带有电源风扇运行的封闭机箱内的温度。
因为这些是 USB 底座，所以我遇到了一些我以前从未见过的麻烦。虽然我可以看到设备为/dev/sda和/dev/sdb，但smartctl昨晚任何命令都会导致错误。lsusb报告码头是 JMicron Technology，快速谷歌搜索表明我需要指定--device选项。在尝试了几件事之后，我放弃了它，因为它似乎不起作用。
今晚，我在没有 --device 的情况下再次尝试，并且无缘无故地工作得更好。
另外请记住，我在一台与网络断开连接的计算机上运行它（纯粹是因为我没有地方插入以太网电缆）。因此，我试图通过smartctl在这台笔记本电脑上运行相应的命令、粘贴输出并调整值以匹配我在测试 PC 的屏幕上看到的内容来捕获我的笔记。我提到这一点是因为我发现自己在粘贴后错过了一个值的更新，所以我想提前道歉，以防万一有人在阅读下面的输出时感到困惑，因为值看起来不对。（仅供参考，当我更新 RAW_VALUE 时，我错过的值是 Temperature_Celsius 的 VALUE/WORST。）
这也意味着我必须在测试 PC 上手动键入上面的脚本。我相信我输入的所有内容都是正确的，但我总是有可能在某处遗漏了逗号或分号。
我执行了以下部分中的步骤两次 - 一次使用前两个驱动器，然后在关闭所有电源后再次使用剩余的两个驱动器替换驱动器，然后重新启动所有驱动器。在适用的情况下，我已经注释了与第二次运行的任何差异。
好的。现在进入有趣的部分......
我使用 System Rescue CD 5.0.3 版的 Live CD 启动了 PC。在我得到提示后，我监控了日志：
# tail -F /var/log/messages
我打开了每个 USB 扩展坞的电源，观察 /dev/sda 和 /dev/sdb 出现的消息。
要运行脚本，我输入：
# ~/scripts/hdd_init_checks.sh 60 /dev/sdX
对于每个磁盘（sda 和 sdb）。
我不知道轮询过于频繁是否会在驱动器上磨损任何东西，但我认为在此期间每分钟一次就足够了。
两个驱动器的初始参数相同：
ID# ATTRIBUTE_NAME VALUE WORST THRESH WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 100 100 016 -
2 Throughput_Performa 100 100 054 -
3 Spin_Up_Time 100 100 024 -
5 Reallocated_Sector_ 100 100 005 -
7 Seek_Error_Rate 100 100 067 -
8 Seek_Time_Performan 100 100 020 -
9 Power_On_Hours 100 100 000 -
10 Spin_Retry_Count 100 100 060 -
12 Power_Cycle_Count 100 100 000 -
193 Load_Cycle_Count 100 100 000 -
194 Temperature_Celsius 250 250 000 - 24 (Min/Max
197 Current_Pending_Sec 100 100 000 -
APM level is: Disabled
我开始运行 SMART 测试；然而，smartctl --capabilities报告这些都不支持运输自检。那好吧。
# smartctl --capabilities /dev/sdX
...
Self-test supported.
No Conveyance Self-test supported.
...
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 571) minutes.
我开始对每个 sda 和 sdb 进行立即离线测试，但首先我检查smartctl --capabilities /dev/sdX了每个驱动器：
Offline data collection status: (0x80) Offline data collection activity
was never started.
Auto Offline Data Collection: Enabled.
...
Total time to complete Offline
data collection: ( 113) seconds.
然后，我开始了即时离线测试：
# smartctl --test=offline /dev/sdX
Testing has begun.
Please wait 113 seconds for test to complete.
Test will complete after Thu Oct 5 03:40:52 2017
在测试期间，我通过以下方式监控其进度smartctl --capabilities：
# watch -n 1 'echo "--- sda"; smartctl --capabilities /dev/sda | head -13 | tail -9; echo "--- sdb"; smartctl --capabilities /dev/sdb | head -13 | tail -9'
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
...
Total time to complete Offline
data collection: ( 113) seconds.
并在完成时查看结果：
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
...
Total time to complete Offline
data collection: ( 113) seconds.
参数现在与上面的有点不同：
ID# ATTRIBUTE_NAME VALUE WORST THRESH WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 100 100 016 -
2 Throughput_Performa 136 136 054 -
3 Spin_Up_Time 100 100 024 -
5 Reallocated_Sector_ 100 100 005 -
7 Seek_Error_Rate 100 100 067 -
8 Seek_Time_Performan 128 128 020 -
9 Power_On_Hours 100 100 000 -
10 Spin_Retry_Count 100 100 060 -
12 Power_Cycle_Count 100 100 000 -
193 Load_Cycle_Count 100 100 000 -
194 Temperature_Celsius 125 125 000 - 48 (Min/Max
197 Current_Pending_Sec 100 100 000 -
APM level is: Disabled
（第二次运行：使用第二对硬盘驱动器，sda 的吞吐量性能为 137，值和最差；sdb 的值与上面匹配。在 31 和 34 时这些温度也较低，但这可能是因为我知道这次我在做什么并轻松完成这些步骤，因此它们还没有变热。）
看起来温度在上升；因为我试图在这里记录我的笔记，它已经结束了几分钟。是 46，然后是 47，现在是 48。驱动器位于标准办公桌的书柜部分，因此它们被封闭在六个面中的五个面中，但我希望它在 PC 机箱内更暖和。我打开房间里的吊扇让空气流通，以防万一。
错误日志显示没有错误：
# smartctl --log=error /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged
接下来，我对 sda 和 sdb 分别进行了两分钟的简短自测：
# smartctl --test=short /dev/sdX
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Thu Oct 5 04:10:34 2017
在测试期间，我通过以下方式监控其进度smartctl --capabilities：
# watch -n 1 'echo "--- sda"; smartctl --capabilities /dev/sda | head -13 | tail -9; echo "--- sdb"; smartctl --capabilities /dev/sdb | head -13 | tail -9'
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
( 248) 80% of test remaining.
( 247) 70% of test remaining.
( 246) 60% of test remaining.
( 245) 50% of test remaining.
( 244) 40% of test remaining.
( 243) 30% of test remaining.
( 242) 20% of test remaining.
( 241) 10% of test remaining.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
（注意：输出看起来并不是这样；我在这里合并了所有不同的百分比，以便于阅读。下面的长测试显示了更真实的输出。）
除了温度似乎在 47 和 48 之间波动之外，参数似乎根本没有变化：
ID# ATTRIBUTE_NAME VALUE WORST THRESH WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 100 100 016 -
2 Throughput_Performa 136 136 054 -
3 Spin_Up_Time 100 100 024 -
5 Reallocated_Sector_ 100 100 005 -
7 Seek_Error_Rate 100 100 067 -
8 Seek_Time_Performan 128 128 020 -
9 Power_On_Hours 100 100 000 -
10 Spin_Retry_Count 100 100 060 -
12 Power_Cycle_Count 100 100 000 -
193 Load_Cycle_Count 100 100 000 -
194 Temperature_Celsius 127 127 000 - 47 (Min/Max
197 Current_Pending_Sec 100 100 000 -
APM level is: Disabled
自检日志没有显示错误：
# smartctl --log=selftest /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 1 -
注意：自检日志中的 LifeTime(hours) 列可以指示自上次测试以来的时间，当与属性 9 中的 Power_On_Hours 结合使用时，可以指示当前生命周期小时数。
（第二次运行：这次 LifeTime(hours) 为 0。同样是因为这次我移动得更快并且更快地完成这些步骤。）
我无法为这些设备运行这个。我试过：
# smartctl --test=conveyance /dev/sdX
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Conveyance Self-test functions not supported
Sending command: "Execute SMART Conveyance self-test routine immediately in off-line mode".
Command "Execute SMART Conveyance self-test routine immediately in off-line mode" failed: scsi error aborted command
太糟糕了。在某处阅读其他人的回复后，我确认了手册页所述，“确定设备运输过程中发生的损坏”。通过快递收到这些后，我很想进行此类测试。
我在深夜启动了最后一次 SMART 测试以在这些驱动器上运行，10 小时后我将无法检查它，所以它必须等到明天晚上 - 从现在开始几乎 24 小时。
# smartctl --test=long /dev/sdX
Testing has begun.
Please wait 571 minutes for test to complete.
Test will complete after Thu Oct 5 13:57:44 2017
在测试期间，我定期使用以下方法监控其进度smartctl
--capabilities：
# watch -n 1 'echo ---- /dev/sda; smartctl --capabilities /dev/sda | head -13 | tail -9; echo ---- /dev/sdb; smartctl --capabilities /dev/sdb | head -13; tail -9'
---- /dev/sda
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
Total time to complete Offline
data collection: ( 113) seconds.
---- /dev/sdb
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
Total time to complete Offline
data collection: ( 113) seconds.
...
我可能在开始后大约 6 小时回来，观察到输出显示剩余 10%，但我知道我不会在附近完成。我确实注意到没有一个 SMART 属性似乎在那里。
我在开始 24 小时后回来并确认测试已完成：
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
由于驱动器整天闲置，它们现在似乎已经冷却下来：
ID# ATTRIBUTE_NAME VALUE WORST THRESH WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 100 100 016 -
2 Throughput_Performa 136 136 054 -
3 Spin_Up_Time 100 100 024 -
5 Reallocated_Sector_ 100 100 005 -
7 Seek_Error_Rate 100 100 067 -
8 Seek_Time_Performan 128 128 020 -
9 Power_On_Hours 100 100 000 -
10 Spin_Retry_Count 100 100 060 -
12 Power_Cycle_Count 100 100 000 -
193 Load_Cycle_Count 100 100 000 -
194 Temperature_Celsius 142 142 000 - 42 (Min/Max 23/50)
197 Current_Pending_Sec 100 100 000 -
APM level is: Disabled
由于某种原因（可能是由于上述 awk 脚本中的拼写错误），Min/Max 被切断，因此我手动运行smartctl --attributes并粘贴了过去输出的值。看起来温度在某个时候达到了 50 度。
自检日志没有显示错误：
# smartctl --log=selftest /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 2 Extended offline Completed without error 00% 10 -
# 1 Short offline Completed without error 00% 1 -
badblocks当我在上面进行长时间的自检时，我在争论是否应该同时执行此部分，或者等到自检完成。对于前两个磁盘，我选择在格式化分区之前让长时间的自检运行完成，所以我在上面的测试运行时写了这一节，但直到 24 小时后我才运行这些步骤以上测试完成。
注意：正如@Xen2050 所述，本节在设备上执行写测试。我不介意在我的硬盘驱动器上运行它；但是，由于写入有限，我会在任何闪存或 SSD 上运行它之前三思而后行。
如果我打算使用 ext2 或 ext4 文件系统，我可以在使用 fdisk/gdisk 分区后运行如下命令来格式化分区：
# mke2fs -c -c /dev/sdX1
根据手册页，第一个-c在创建文件系统之前检查坏块，第二个-c执行较慢的读写测试。
手册页还警告使用该-c选项而不是badblocks直接运行。
但是，我不打算在这些驱动器上放置任何ext文件系统，所以我决定badblocks直接运行。
温度似乎在42到43之间波动；否则，其他一切都是静态的：
ID# ATTRIBUTE_NAME VALUE WORST THRESH WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 100 100 016 -
2 Throughput_Performa 136 136 054 -
3 Spin_Up_Time 100 100 024 -
5 Reallocated_Sector_ 100 100 005 -
7 Seek_Error_Rate 100 100 067 -
8 Seek_Time_Performan 128 128 020 -
9 Power_On_Hours 100 100 000 -
10 Spin_Retry_Count 100 100 060 -
12 Power_Cycle_Count 100 100 000 -
193 Load_Cycle_Count 100 100 000 -
194 Temperature_Celsius 139 139 000 - 43 (Min/Max
197 Current_Pending_Sec 100 100 000 -
APM level is: Disabled
我们现在在写测试之前有一个基线。
badblocks现在，我准备在sda和上运行坏块sdb：
# time badblocks -s -v -w /dev/sdX
Checking for bad blocks in read-write mode
From block 0 to 3907018583
Testing with pattern 0xaa: 0.00% done, 0:55 elapsed. (0/0/0 errors)
与上面的扩展测试一样，我同时在两个驱动器上运行它。
15-20分钟后我回来了；两个驱动器的温度现在都为 46 度，看起来已经完成了 0.02%。
Testing with pattern 0xaa: 0.02% done, 18:33 elapsed. (0/0/0 errors)
如果我的数学计算正确，这意味着测试将需要大约 100000 分钟或 70 天才能完成。恐怕我没有那么多时间，因为我还有两个驱动器要检查，而且只有 30 天的退货/换货期，所以稍后我会担心这个。
又过了 15 分钟左右，我中止了测试。SMART 属性与上述相同，只是温度不同。
如前所述，如果我有时间或者驱动器更小，我可以让写测试继续完成。
或者，如果我想将驱动器归零，我可以这样做：
# dd if=/dev/zero of=/dev/sdX bs=1M
这样做时，我可以监控 SMART 属性是否有任何剧烈变化。
根据@sawdust 的建议，驱动器已经启动了 24 小时，我在此期间观察了 SMART 属性。
（第二次运行：这是我最终为这两个驱动器做的一段时间。）
此时，我关闭了驱动器并更换了两个额外的新驱动器，并如前所述为它们执行了上述所有步骤。
大多数 SMART 监控工具在检测到问题时都会发出警报，我认为需要注意的是“当前待定扇区”和“重新分配的扇区计数”，但一些错误显然很常见。
也运行所有SMART自检，离线，短，长，运输测试应该特别适用，它“旨在识别设备在运输过程中发生的损坏”。
有关smartctl详细信息，请参阅的手册页，或Smartmontools 上的 Ubuntu 社区帮助 Wiki
格式化驱动器时，让它运行写入测试badblocks（或在格式化之前自己运行，显然并非所有 mkfs 都支持它），它会写入0's, 1's, 01's 和10's 并且应该是一个很好的锻炼，检查SMART 数据也适用于任何急剧增加的数字。
如果它是闪存设备或 SSD，您可能要记住它们的写入生命周期有限，但是体面的 SSD [我在测试中读过] 在失败之前它们应该处理疯狂的写入量，例如常量写了几个月，远远超过正常使用，所以不用担心。]
检查驱动器的停转超时，过去有一些驱动器每 2 或 3 分钟就会停转一次，这确实在创纪录的时间内磨损了驱动器。在 linux 中，计时和减速驱动器通常是其他程序的责任，但要注意驱动器本身。
如果您可以监控驱动器的温度，请执行此操作。hddtemp应该管用。一个驱动器比其他驱动器显着热将是一个关于驱动器的危险信号，或者只是它正在冷却。
如果制造商有特定的测试/监控程序，请尝试一下。他们应该更深入地了解驱动器的细节。
| 归档时间： |
|
| 查看次数： |
4976 次 |
| 最近记录： |