我即将购买几块全新的 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任何命令都导致错误。报告称这些基座是 JMicron Technology，而且很快smartctllsusb谷歌搜索指示我需要指定--device选项。尝试了几种方法后，我放弃了，因为它似乎不起作用。
今晚，我再次尝试不使用--device，结果不知为何它运行得更好了。
还请记住，我在一台与网络断开连接的计算机上运行此程序（纯粹是因为我没有地方插入以太网电缆）。因此，我试图通过在smartctl这台笔记本电脑上运行相应的命令、粘贴输出并调整值以匹配我在测试 PC 屏幕上看到的内容来记录我的笔记。我提到这一点是因为我发现自己在粘贴后错过了一个值的更新，所以我想提前道歉，以防有人对下面的输出感到困惑，因为值看起来不对，所以这不完全合理。（仅供参考，当我更新 RAW_VALUE 时，我错过的值是 Temperature_Celsius 的 VALUE/WORST。）
这也意味着我必须手动将上述脚本输入到测试电脑上。我相信我输入的所有内容都是正确的，但总有可能我在某个地方漏掉了逗号或分号。
我执行了以下部分中的步骤两次——第一次使用前两个驱动器，第二次关闭所有驱动器后，用剩余两个驱动器替换驱动器，然后重新启动所有驱动器。我已注释了与第二次运行的任何差异（如果适用）。
好的。现在开始有趣的部分...
我使用 System Rescue CD 版本 5.0.3 的实时 CD 启动了 PC。出现提示后，我监控了日志：
# tail -F /var/log/messages
我打开了每个 USB 底座的电源并观察 /dev/sda 和 /dev/sdb 出现的消息。
运行 SMART 属性监控脚本
要运行脚本，我输入：
# ~/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 测试
我开始运行 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 的 Throughput_Performance VALUE 和 WORST 为 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（小时）列与属性 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.
...
大约在启动后六小时我回来了，发现输出显示剩余 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 脚本中的拼写错误），最小值/最大值被截断，因此我手动运行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直接运行。
不过，我不打算在这些驱动器上放置任何扩展文件系统，所以我决定badblocks直接运行。
测试前检查 SMART 属性
温度似乎在 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 天的退货/换货期，所以我以后再担心这个问题。
测试后检查 SMART 属性
又过了 15 分钟左右，我中止了测试。SMART 属性与上面相同，只是温度不同。
额外检查
如上所述，如果我有时间或者驱动器较小，我可以让写入测试继续完成。
或者，如果我想将驱动器清零，我可以这样做：
# dd if=/dev/zero of=/dev/sdX bs=1M
在这样做的同时，我可以监视 SMART 属性是否存在任何剧烈变化。
按照@sawdust 的建议，驱动器已经启动了 24 小时，在此期间我观察了 SMART 属性。
（第二次运行：这就是我最终为这两个驱动器所做的事情。）
对其他驱动器重复上述操作
这时，我关闭了驱动器并更换了两个新的驱动器，并按照前面所述的所有步骤对它们进行了操作。
答案1
大多数 SMART 监控工具如果检测到某些问题，都会自行发出警报，我认为需要注意的几个是“当前待处理扇区”和“重新分配的扇区数”，但显然有几个错误很常见。
运行所有 SMART 自检，离线、短距离、长距离，并且运输测试应该特别适用，它“旨在识别设备在运输过程中造成的损坏”。
请参阅
smartctl手册页了解更多信息，或者Ubuntu 社区帮助 Wiki 上的 Smartmontools格式化驱动器时，让其运行写入测试
badblocks（或者在格式化之前自己运行，显然并非所有 mkfs 都支持它），它会写入0's、1's、01's 和10's，应该是一个很好的锻炼，之后也检查 SMART 数据是否有任何急剧增加的数字。如果它是闪存设备或 SSD，您可能需要记住它们的写入寿命有限，但不错的 SSD [我在测试中读到过] 在发生故障之前应该可以处理大量的写入，例如连续数月的持续写入，远远超过正常使用，所以不用担心。]
检查驱动器的旋转停止超时，过去有些驱动器每 2 或 3 分钟就会旋转停止一次，这会在创纪录的时间内真正磨损驱动器。在 Linux 中，通常由其他程序负责计时和旋转停止驱动器，但要小心驱动器本身。
如果您可以监控驱动器的温度，请这样做。
hddtemp应该可以。一个驱动器比其他驱动器热得多，这可能是驱动器的危险信号，或者只是驱动器正在冷却。
如果制造商有特定的测试/监控程序，请尝试一下。他们应该对驱动器的具体细节有更深入的了解。