mdadm RAID5 随机读取错误。死盘？

Question

首先是长篇故事：
我在 Debian 9 上有一个带 mdadm 的 RAID5。Raid 有 5 个磁盘，每个 4TB 大小。其中4个是HGST Deskstar NAS，后来的一个是东芝N300 NAS。

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

重新启动后，我的 BIOS 注意到 SATA 端口 3 上的 HGST 驱动器的 SMART 状态不好。smartctl 曾对我说存在 DMA CRC 错误，但声称驱动器没问题。

稍后再次重新启动，我再也看不到 smart 中的 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。我试图制作一个完全相同大小的分区，但没有奏效。分区程序声称我的数字太大（我用字节和扇区尝试过）。所以我只是让分区尽可能大。但现在看起来是一样的大小，我有点困惑。

sdc是旧的，sdh是新的

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）已经在 crypt 卷中。

问题：
mdadm 在什么条件下会说磁盘出现故障？
随机读取错误可能来自一个损坏的磁盘吗？
当磁盘发送错误数据时不检测RAID吗？
当备用磁盘的大小不完全相同时，手动将磁盘标记为故障是否危险？

Answer 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。不知道如何从我的头顶，但你可以谷歌。