为什么我的 mdadm raid-1 恢复这么慢?

为什么我的 mdadm raid-1 恢复这么慢?

在我正在运行 Ubuntu 10.04 的系统上。我的 raid-1 恢复开始时很快,但很快就变得非常慢(按照这个速度,恢复将需要 150 天!):

dimmer@paimon:~$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdc1[2] sdb1[1]
      1953513408 blocks [2/1] [_U]
      [====>................]  recovery = 24.4% (477497344/1953513408) finish=217368.0min speed=113K/sec

unused devices: <none>

尽管我已将内核变量设置为合理的快速值:

dimmer@paimon:~$ cat /proc/sys/dev/raid/speed_limit_min
1000000

dimmer@paimon:~$ cat /proc/sys/dev/raid/speed_limit_max
100000000

我使用的是 2 个 2.0TB 西部数据硬盘,WDC WD20EARS-00M 和 WDC WD20EARS-00J。我相信它们已经分区,因此它们的扇区是对齐的。

dimmer@paimon:/sys$ sudo parted /dev/sdb
GNU Parted 2.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) p                                                                
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2000GB  2000GB  ext4

(parted) unit s

(parted) p                                                                

Number  Start  End          Size         File system  Name  Flags
 1      2048s  3907028991s  3907026944s  ext4

(parted) q                                                                
dimmer@paimon:/sys$ sudo parted /dev/sdc
GNU Parted 2.2
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: ATA WDC WD20EARS-00J (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2000GB  2000GB  ext4

我开始认为我遇到了硬件问题,否则我无法想象为什么 mdadm 恢复会这么慢。

我使用 Ubuntu 的磁盘实用程序 GUI 应用程序对 /dev/sdc 进行了基准测试,结果看起来很正常,所以我知道 sdc 能够以比这更快的速度写入。我在 RMAd 的类似 WD 驱动器上也遇到了同样的问题,原因是坏扇区。我想他们可能也给我寄了一个有坏扇区的替换件,尽管目前还没有 SMART 值显示它们。

有什么想法吗?谢谢。

根据要求,top 的输出按 CPU 使用率排序(请注意,CPU 使用率约为 0)。iowait 也为零,这看起来很奇怪:

top - 11:35:13 up 2 days,  9:40,  3 users,  load average: 2.87, 2.58, 2.30
Tasks: 142 total,   1 running, 141 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3096304k total,  1482164k used,  1614140k free,   617672k buffers
Swap:  1526132k total,        0k used,  1526132k free,   535416k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                  
   45 root      20   0     0    0    0 S    0  0.0   2:17.02 scsi_eh_0                                                                                 
    1 root      20   0  2808 1752 1204 S    0  0.1   0:00.46 init                                                                                      
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd                                                                                  
    3 root      RT   0     0    0    0 S    0  0.0   0:00.02 migration/0                                                                               
    4 root      20   0     0    0    0 S    0  0.0   0:00.17 ksoftirqd/0                                                                               
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                                
    6 root      RT   0     0    0    0 S    0  0.0   0:00.02 migration/1
  ...                                                               

dmesg 错误,看起来肯定像是硬件问题:

[202884.000157] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[202884.007015] ata5.00: failed command: FLUSH CACHE EXT
[202884.013728] ata5.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[202884.013730]          res 40/00:00:ff:59:2e/00:00:35:00:00/e0 Emask 0x4 (timeout)
[202884.033667] ata5.00: status: { DRDY }
[202884.040329] ata5: hard resetting link
[202889.400050] ata5: link is slow to respond, please be patient (ready=0)
[202894.048087] ata5: COMRESET failed (errno=-16)
[202894.054663] ata5: hard resetting link
[202899.412049] ata5: link is slow to respond, please be patient (ready=0)
[202904.060107] ata5: COMRESET failed (errno=-16)
[202904.066646] ata5: hard resetting link
[202905.840056] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[202905.849178] ata5.00: configured for UDMA/133
[202905.849188] ata5: EH complete
[203899.000292] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[203899.007096] ata5.00: failed command: IDENTIFY DEVICE
[203899.013841] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
[203899.013843]          res 40/00:00:ff:f9:f6/00:00:38:00:00/e0 Emask 0x4 (timeout)
[203899.041232] ata5.00: status: { DRDY }
[203899.048133] ata5: hard resetting link
[203899.816134] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[203899.826062] ata5.00: configured for UDMA/133
[203899.826079] ata5: EH complete
[204375.000200] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[204375.007421] ata5.00: failed command: IDENTIFY DEVICE
[204375.014799] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
[204375.014800]          res 40/00:00:ff:0c:0f/00:00:39:00:00/e0 Emask 0x4 (timeout)
[204375.044374] ata5.00: status: { DRDY }
[204375.051842] ata5: hard resetting link
[204380.408049] ata5: link is slow to respond, please be patient (ready=0)
[204384.440076] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[204384.449938] ata5.00: configured for UDMA/133
[204384.449955] ata5: EH complete
[204395.988135] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[204395.988140] ata5.00: failed command: IDENTIFY DEVICE
[204395.988147] ata5.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
[204395.988149]          res 40/00:00:ff:0c:0f/00:00:39:00:00/e0 Emask 0x4 (timeout)
[204395.988151] ata5.00: status: { DRDY }
[204395.988156] ata5: hard resetting link
[204399.320075] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[204399.330487] ata5.00: configured for UDMA/133
[204399.330503] ata5: EH complete

答案1

在 raid hdparm -W 0 /dev/sdX 中禁用硬盘上的写入缓存。同时尝试不要加载正在重建的磁盘。

您还可以尝试将 SATA 速度限制为 150 MB(看起来它们连接到主板 SATA 端口,但会滞后)。

答案2

问题最终是由硬件引起的。最后,我把所有硬盘从底盘上卸下来,并将它们移到塔内的新位置,然后我尝试拔掉那些我知道不需要的外围设备。这解决了问题。RAID 阵列很快就重建了,我的 RAID 阵列已经稳定了好几个月。

不幸的是,我不知道问题的具体原因。我猜是某些东西给数据链路带来了噪音,但我真的不知道。我的主板是华硕 P5WDG2 WS Pro,以防其他人遇到这款主板的类似问题。

感谢所有试图提供帮助的人——这只是一个极端案例。

答案3

祝你好运,这只是一个电源消耗问题(虽然当我的硬盘驱动器上的固件出现问题时我也遇到了这个错误),我看到与此相关的内核错误上有大量活动。

https://bugs.launchpad.net/debian/+source/linux/+bug/256637

也许这适用于你?我无法进入 Linux 内核错误跟踪器,因此我无法判断它出现在哪个版本中,以及它是否曾经被修复(以及它与 10.04 有何关系)。

您没有将此 RAID 迁移到此 Ubuntu 盒子,对吗?您已在此芯片组上运行此 RAID 一段时间了,对吗?

相关内容