32 hard-drive smart
man smartctl 状态（为简洁起见被剪掉）：
在第一类，称为“在线”测试。在第二类测试被称为“离线”的测试。通常，磁盘会在进行磁盘访问时暂停离线测试，然后在磁盘空闲时自动恢复它。在第三类测试（和其'testing'实在是一个合适的选择单词的唯一类别）是“自我”测试。
启用或禁用 SMART 自动离线测试，它每四小时扫描一次驱动器是否存在磁盘缺陷。可以在正常系统操作期间给出该命令。
谁运行测试驱动固件？这些是什么类型的测试 - 固件是否读/写到磁盘 - 到底发生了什么？在操作系统 (linux) 中调用测试是否安全，或者可以安排稍后的测试 - 这是如何发生的 - 当您在 BIOS 提示下重新启动操作系统（“离线测试”）时？结果显示在哪里 - SMART 日志？
Mad*_*ter 43
驱动器固件运行测试。
测试的详细信息可以在例如 www.t13.org/Documents/UploadedDocuments/technical/e01137r0.pdf 中阅读，其中总结了短期和长期测试的元素：
一个电气部分，其中驱动器测试自己的电子设备。此部分中的特定测试是特定于供应商的，但作为示例：此部分可能包括诸如缓冲 RAM 测试、读/写电路测试和/或读/写磁头元件测试之类的测试。
寻道/伺服段，其中驱动器测试其在数据磁道上查找和伺服的能力。此测试中使用的特定方法也是特定于供应商的。
读取/验证扫描段，其中驱动器执行磁盘表面某些部分的读取扫描。扫描表面的数量和位置取决于完成时间限制并且是特定于供应商的。
扩展自检的标准与短自检相同，但有两个例外：扩展自检的第 (3) 段应是对所有用户数据区的读取/验证扫描，并且没有驱动器执行测试的最大时间限制。
在操作系统运行时执行无损测试是安全的，但可能会影响一些性能。正如smartctl手册页对-t shortand所说的那样-t long，
可以在正常系统操作中给出此命令（除非在捕获模式下运行）
如果您使用 调用俘虏模式-C，则smartctl假定驱动器可能因忙而无法使用。这不应该在操作系统正在使用的驱动器上完成。
正如手册页所暗示的那样，离线测试（这只是意味着定期后台测试）并不可靠，并且从未正式成为 ATA 规范的一部分。相反，我从 cron 运行我的；这样我就知道它们什么时候应该发生，如果需要，我可以阻止它。
smartctl输出中看到。这是一个正在运行的测试：[root@risby 图像]# 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 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 扩展离线完成无错误 00% 20567 - # 2 扩展离线完成无错误 00% 486 - SMART 选择性自检日志数据结构修订号 0 注意：修订号不是 1 表示从未运行过选择性自检 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 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%）。
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
...
本白皮书阐明了日志中出现的错误代码。常见的错误缩写有：
就我而言，IDNF 错误（ID 未找到）可以追溯到驱动器通过 USB-to-SATA 适配器插入时发生的事件，并且碰巧供电不足，这导致它无法正确搜索。