mdadm RAID5 随机读取错误。磁盘快坏了?

mdadm RAID5 随机读取错误。磁盘快坏了?

首先说一个长故事:
我在 Debian 9 上有一个带有 mdadm 的 RAID5。该 Raid 有 5 个磁盘,每个磁盘大小为 4TB。其中 4 个是 HGST Deskstar NAS,后来的一个是 Toshiba N300 NAS。

在过去的几天里,我注意到该 Raid 中存在一些读取错误。例如,我有一个 10GB 的 rar 档案,分为多个部分。当我尝试提取时,我在某些部分上遇到了 CRC 错误。如果我第二次尝试,我会在其他部分上遇到这些错误。下载 Torrent 和重新检查后也会发生这种情况。

重新启动后,我的 BIOS 注意到 SATA 端口 3 上的 HGST 驱动器的 SMART 状态不佳。smartctl 告诉我存在 DMA CRC 错误,但声称驱动器正常。

再次重启后,我再也看不到智能中的 crc 错误了。但现在我得到了这个输出

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-4-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always   FAILING_NOW 1989

由于 HGST 不再以正常价格出售,我购买了另一台东芝 N300 来替换 HGST。两者都标为 4TB。我尝试制作一个大小完全相同的分区,但没有成功。分区程序声称我的数字太大(我尝试使用字节和扇区)。所以我只是将分区做得尽可能大。但现在看起来大小相同,我有点困惑。

南达科他州是旧的,同步双链是新的

Disk /dev/sdc: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4CAD956D-E627-42D4-B6BB-53F48DF8AABC

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 7814028976 7814026929  3,7T Linux RAID


Disk /dev/sdh: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3A173902-47DE-4C96-8360-BE5DBED1EAD3

Device     Start        End    Sectors  Size Type
/dev/sdh1   2048 7814037134 7814035087  3,7T Linux filesystem

目前我已将新磁盘添加为备用磁盘。RAID 仍可与旧驱动器配合使用。我仍然遇到一些读取错误,尤其是在读取大文件时。

这是我的 RAID 当前的样子:

/dev/md/0:
        Version : 1.2
  Creation Time : Sun Dec 17 22:03:20 2017
     Raid Level : raid5
     Array Size : 15627528192 (14903.57 GiB 16002.59 GB)
  Used Dev Size : 3906882048 (3725.89 GiB 4000.65 GB)
   Raid Devices : 5
  Total Devices : 6
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sat Jan  5 09:48:49 2019
          State : clean
 Active Devices : 5
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

           Name : SERVER:0  (local to host SERVER)
           UUID : 16ee60d0:f055dedf:7bd40adc:f3415deb
         Events : 25839

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       33        1      active sync   /dev/sdc1
       3       8        1        2      active sync   /dev/sda1
       4       8       17        3      active sync   /dev/sdb1
       5       8       80        4      active sync   /dev/sdf

       6       8      113        -      spare   /dev/sdh1

磁盘结构如下

NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                          8:0    0   3,7T  0 disk
└─sda1                       8:1    0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdb                          8:16   0   3,7T  0 disk
└─sdb1                       8:17   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdc                          8:32   0   3,7T  0 disk
└─sdc1                       8:33   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdd                          8:48   0   3,7T  0 disk
└─sdd1                       8:49   0   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume
sdf                          8:80   1   3,7T  0 disk
└─md0                        9:0    0  14,6T  0 raid5
  └─storageRaid            253:4    0  14,6T  0 crypt
    └─vg_raid-raidVolume   253:5    0  14,6T  0 lvm   /media/raidVolume
sdh                          8:112  1   3,7T  0 disk
└─sdh1                       8:113  1   3,7T  0 part
  └─md0                      9:0    0  14,6T  0 raid5
    └─storageRaid          253:4    0  14,6T  0 crypt
      └─vg_raid-raidVolume 253:5    0  14,6T  0 lvm   /media/raidVolume

我有点困惑,备用磁盘(sdh)已经在加密卷中了。

问题:
mdadm 会在什么条件下判断磁盘已发生故障?
随机读取错误是否可能来自一个损坏的磁盘?
当磁盘发送错误数据时,无法检测到 raid?
当备用磁盘的大小不完全相同时,手动将磁盘标记为故障是否危险?

答案1

在我看来,MD raid 在踢出磁盘方面过于保守。我总是在 syslog/dmesg 中观察 ATA 异常(我设置 rsyslog 来通知我这些异常)。

我必须说,我很惊讶你在应用程序级别遇到错误。RAID5 应该使用奇偶校验信息来检测错误(编辑,显然,它没有;仅在验证期间)。话虽如此,无论磁盘是否是原因,这都是糟糕的。近 2000 个重新分配的扇区确实很糟糕。

分区可以更大,否则您也无法将它们添加为备用分区,但为了确保一切正常,您可以使用 fdisk、sfdisk 和 gdisk 克隆分区表。您有 GPT,所以让我们使用它的备份功能。如果有gdisk /dev/sdX,您可以使用b将分区表备份到磁盘。然后,在新磁盘上,gdisk /dev/sdY您可以使用r恢复选项,然后l加载备份。然后您应该有一个相同的分区,所有mdadm --manage --add命令都应该可以工作。(在更改分区表之前,您需要从阵列中取出新磁盘)

我实际上倾向于在服务器上保留这些备份分区表。这样可以快速更换磁盘。

最后一条建议:不要使用 RAID5。磁盘如此之大,RAID5 就不可靠了。您应该能够添加磁盘并动态迁移到 RAID6。我不太清楚具体怎么做,但您可以谷歌一下。

答案2

让 cron 任务启动奇偶校验不匹配检查是很常见的。我很确定 debian 9 在安装 mdadm 包时默认会执行此操作,因此您的系统日志会有相关报告。

此外,如果你的系统内存出现故障,这可能是主要原因

相关内容