标签: smart

我已经尝试了 nagios 到 SMART 监控的最佳插件。有一些，但只监测温度。但是使用 smartctl 我们可以找到更多数据。您是否有一些更好的插件，其中包含来自 smart 的所有数据？

我有两个硬盘驱动器在我的服务器上设置为 RAID 1 阵列（Linux，使用 mdadm 的软件 RAID），其中一个在 syslog 中给了我这个“礼物”：

Nov 23 02:05:29 h2 kernel: [7305215.338153] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Nov 23 02:05:29 h2 kernel: [7305215.338178] ata1.00: irq_stat 0x40000008
Nov 23 02:05:29 h2 kernel: [7305215.338197] ata1.00: failed command: READ FPDMA QUEUED
Nov 23 02:05:29 h2 kernel: [7305215.338220] ata1.00: cmd 60/08:00:d8:df:da/00:00:3a:00:00/40 tag 0 ncq 4096 in
Nov 23 02:05:29 h2 kernel: [7305215.338221]          res 41/40:08:d8:df:da/00:00:3a:00:00/00 Emask 0x409 (media error) <F>
Nov 23 02:05:29 h2 kernel: [7305215.338287] ata1.00: …

在我开始之前，快速免责声明。我基本上是一个因环境而被迫担任系统管理员角色的开发人员，所以如果我说一些愚蠢的话或看起来我不知道自己在做什么，我会提前道歉。

因此，我们的主服务器上的硬盘之一出现了问题。/dev/sda有两个分区，一个挂载为/，另一个用作 PostgreSQL 数据驱动器 ( /dev/sda2)。

$ df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                   92G   13G   75G  14% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                   1.6G   12M  1.6G   1% /run
/dev/disk/by-uuid/8ffca87a-ffe4-4c39-ab30-352b61f039f8   92G   13G   75G  14% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                   3.2G     0  3.2G   0% /run/shm
/dev/sda2                                               826G   66G  719G   9% /var/lib/data/vol1
/dev/sdb1                                               917G   75G  797G   9% /var/lib/data/vol2

（/dev/sda1 出于某种原因使用其 UUID 挂载）

最近，它开始经历 100% IO R/W 的间隔，在此期间系统实际上被阻塞并且无法执行最简单的任务。

dmesg 的简短摘录： …

几周前，我购买了一台新的 Western Digital Elements 3TB。

像往常一样，我做了所有 SMART 测试，然后是坏块，然后再次进行 SMART 测试。

当我第一次拿到驱动器时​​，SMART 显示了以下内容：

 Short self-test routine 
 recommended polling time:   (   2) minutes.
 Extended self-test routine
 recommended polling time:   (   7) minutes.

然后我运行了一个简短的 SMART 测试和一个长时间的 SMART 测试，结果正常：

 SMART Self-test log structure revision number 1
 Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
 # 1  Extended offline    Completed without error       00%         0         -
 # 2  Short offline       Completed without error       00%         0         -

然后，我运行了完整的badblocks 破坏性写入测试，没有显示坏块。

然后，我运行了另一个 SMART 简短自检，结果也正常：

 SMART Self-test log structure revision number …

大约 18 个月前，我买了一个 1TB 的 Seagate Barracuda 7200.12 - ST31000528AS 驱动器，因为它有 5 年的保修期，并将它与 Ubuntu Server 下的三星 Spinpoint 一起用作软件 RAID-1 阵列的一半。

昨天smartd开始报告一个问题：

Jan 18 06:08:03 svr smartd[2672]: Device: /dev/sdb [SAT], 2 Currently unreadable (pending) sectors
Jan 18 06:08:03 svr smartd[2672]: Device: /dev/sdb [SAT], 2 Offline uncorrectable sectors

我随后通过 smartctl 进行了调查……并且在安排了一些测试后，我得到了以下结果：

$ smartctl -l error /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.0.0-14-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: …

在我的一个硬盘上，我从 smart 得到了一个糟糕的测试结果，如下所示：

# 1  Extended offline    Completed: read failure       90%     19889         128652505
# 2  Short offline       Completed: read failure       10%     19882         128652505

据我了解，这意味着“仅”存在一些坏块，如何将它们标记为不使用？该磁盘正在软件 raid 中运行。

我有一个硬盘驱动器，它是 Linux 软件 raid5 阵列的一部分。SMART 报告说它的 multi_zone_error_rate 是 0，然后是 1，然后是 3。所以我想我最好开始更频繁地备份并准备更换驱动器。现在，今天，同一个驱动器的 multi_zone_error_rate 又回到了 1。在我不看的时候，似乎有 2 个错误没有发生。

我还通过检查服务器上的系统日志看到了类似的行为。

Jun  7 21:01:17 FS1 smartd[25593]: Device: /dev/sdc, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 100
Jun  7 21:01:17 FS1 smartd[25593]: Device: /dev/sde, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 100
Jun  7 21:01:18 FS1 smartd[25593]: Device: /dev/sdg, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 100
Jun  8 02:31:18 FS1 smartd[25593]: Device: /dev/sdg, SMART Usage Attribute: 7 Seek_Error_Rate …

我有几个存储阵列，其中大量驱动器已通电 25,000 - 30,000 小时（2.8 - 3.4 年）。这些驱动器没有其他问题或错误。

我想知道的是：是否存在仅驱动器老化就足以更换驱动器的重要因素，即使驱动器工作正常且没有错误？

（我很想知道人们是否倾向于运行驱动器直到它们出现故障或开始抛出错误，或者是否有人使用开机时间作为指标采取主动更换方法。）

驱动器制造商通常将企业驱动器的 MTBF 报价为 1,000,000 到 1,500,000 小时，但这些数字在现实世界中并没有多大意义。

我确实找到了 2007 年完成的这项研究：

现实世界中的磁盘故障：1,000,000 小时的 MTTF 对您意味着什么？

http://www.cs.cmu.edu/~bianca/fast07.pdf

该研究表明，在 1 年和 5-7 年之间有一个“最佳点”，您可以预期更少的失败。这些时间之前/之后的驱动器年龄往往要高得多。

如何在 CoreOS 中查看硬盘 ( SMART )的状态？

smartd和smartctl不是CoreOS的一部分。
因此，遵循 CoreOS 理念 smartd 将在容器内运行，因为systemd 单元和 smartctl 将从toolbox 中使用。

我无法从工具箱访问硬盘驱动器。

对我来说，从 SMART 导出的一个磁盘的温度读数与 RAID 1 配置中的双胞胎的温度读数相差多达9°C，这对我来说似乎很奇怪：

# smartctl -d scsi -A /dev/sg1
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     34 C
Drive Trip Temperature:        68 C

# smartctl -d scsi -A /dev/sg2
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature:     43 C
Drive Trip Temperature:        68 C

该服务器是一款1U的Dell PowerEdge R210与规格在这里。造成这种异常的原因可能是什么？