![mdadm RAID5 随机读取错误。磁盘快坏了?](https://linux22.com/image/731626/mdadm%20RAID5%20%E9%9A%8F%E6%9C%BA%E8%AF%BB%E5%8F%96%E9%94%99%E8%AF%AF%E3%80%82%E7%A3%81%E7%9B%98%E5%BF%AB%E5%9D%8F%E4%BA%86%EF%BC%9F.png)
首先说一个长故事:
我在 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 包时默认会执行此操作,因此您的系统日志会有相关报告。
此外,如果你的系统内存出现故障,这可能是主要原因