☰

SMART 测试起什么作用以及它如何发挥作用？

tag-icon • tag-icon hard-drive smart
SMART 测试起什么作用以及它如何发挥作用？

man smartctl状态（为简洁起见，已删除）：

这第一类，称为“在线”测试。第二类测试称为“离线”测试。通常，磁盘将在磁盘访问时暂停离线测试，然后在磁盘空闲时自动恢复测试。第三类测试（并且是唯一真正适合用“测试”这个词的类别）是“自我”测试。

启用或禁用 SMART 自动离线测试，该测试每四小时扫描一次驱动器以查找磁盘缺陷。此命令可以在系统正常运行期间发出。

谁运行测试 - 驱动固件？这些测试是什么类型 - 固件是否读取/写入磁盘 - 具体发生了什么？在操作系统 (linux) 中调用测试是否安全，或者是否可以安排稍后进行测试 - 这是如何进行的 - 当您在 BIOS 提示符下重新启动操作系统时（“离线测试”）？结果显示在哪里 - SMART 日志？

答案1

  1. 驱动器固件运行测试。

  2. 测试的详细信息可以在以下网址阅读：T13/E01137r0（2001 年，由 Wayback Machine 捕获），其中总结了短期测试和长期测试的要素如下：

  3. 电气部分，驱动器测试其自身的电子设备。此部分中的特定测试是特定于供应商的，但作为示例：此部分可能包括诸如缓冲区 RAM 测试、读/写电路测试和/或读/写头元件测试之类的测试。

  4. 寻道/伺服部分，驱动器测试其查找和伺服数据轨道的能力。此测试中使用的特定方法也是特定于供应商的。

  5. 读取/验证扫描段，其中驱动器对磁盘表面的某些部分执行读取扫描。扫描的表面数量和位置取决于完成时间限制，并且特定于供应商。

  6. 扩展自检的标准与短自检相同，但有两点例外：扩展自检的第 (3) 段应对所有用户数据区域进行读取/验证扫描，并且驱动器执行测试没有最大时间限制。

  7. 在操作系统运行时执行非破坏性测试是安全的，尽管可能会对性能产生一些影响。正如smartctl手册页对-t short和所述-t long，

该命令可以在正常系统操作中发出（除非在强制模式下运行）

如果您使用 调用捕获模式-C，smartctl则假定驱动器可能忙到不可用。这应该不是在操作系统正在使用的驱动器上完成。

正如手册页所指出的，离线测试（即定期后台测试）并不可靠，并且从未正式成为 ATA 规范的一部分。相反，我通过 cron 运行测试；这样我就知道应该在什么时候进行测试，如果需要，我可以停止测试。

  1. 结果可以在smartctl输出中看到。以下是正在运行的测试：
[root@risby images]# smartctl -a /dev/sdb
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.6-201.fc22.x86_64]（本地构建）
版权所有 (C) 2002-15，Bruce Allen、Christian Franke，www.smartmontools.org
[...]
SMART 自检日志结构修订号 1
编号 测试描述 状态 剩余寿命（小时） LBA_of_first_error
# 1 扩展离线 无错误完成 00% 20567 -
# 2 扩展离线 无错误完成 00% 486 -
    
SMART 选择性自检日志数据结构修订号 0
注意：修订号不为 1 表示从未运行过选择性自检
跨度 最小 LBA 最大 LBA 当前测试状态
   1 0 0 Self_test_in_progress [剩余 90%] (0-65535)
   2 0 0 未测试
   3 0 0 未测试
   4 0 0 未测试
   5 0 0 未测试

注意两个之前完成的测试（分别在通电 486 和 20567 小时时）和当前正在运行的测试（完成 10%）。

答案2

SMART 的实现取决于制造商，有时可以通过smart -a命令获取相当广泛的日志。以下是我在自加密驱动器上从日立：

SMART Error Log Version: 1
ATA Error Count: 3

Error 3 occurred at disk power-on lifetime: 2543 hours (105 days + 23 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 08 00 08 00 00  Error: IDNF at LBA = 0x00000800 = 2048

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
-- -- -- -- -- -- -- --  ----------------  --------------------
60 08 68 00 08 00 40 00      00:00:06.139  READ FPDMA QUEUED
27 00 00 00 00 00 e0 00      00:00:06.126  READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 a0 00      00:00:06.125  IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00      00:00:06.125  SET FEATURES [Set transfer mode]
27 00 00 00 00 00 e0 00      00:00:06.125  READ NATIVE MAX ADDRESS EXT
...

本白皮书阐明日志中出现的错误代码。常见的错误缩写有：

  • AMNF—未找到地址标记
  • TONF - 未找到轨道 0
  • ABRT - 命令中止
  • IDNF—未找到扇区 ID
  • UNC-- 无法更正的数据
  • BBK——坏块标记

就我而言，IDNF 错误（未找到 ID）可以追溯到驱动器通过 USB 转 SATA 适配器插入时恰好电力不足，导致其无法正常寻道的事件。

相关内容