mdadmRAID5ランダム読み取りエラー。死にかけているディスク？
最初の長い話：
Debian 9でmdadmを使用してRAID5を持っています。RAIDには5つのディスクがあり、各サイズは4TBです。そのうちの4つはHGSTDeskstar NASで、後に登場したのはToshiba N300NASです。
過去数日間、私はそのレイドからのいくつかの読み取りエラーに気づきました。たとえば、私は複数の部分で10GBのrarアーカイブを持っていました。抽出しようとすると、一部のパーツでCRCエラーが発生します。もう一度試すと、他の部分でこれらのエラーが発生します。これは、Torrentとダウンロード後の再チャッキングでも発生します。
再起動後、BIOSは、SATAポート3のHGSTドライブのS.M.A.R.Tステータスが不良であることに気付きました。 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は通常の価格では利用できなくなったため、HGSTの代わりに東芝N300をもう1つ購入しました。どちらも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は、ディスクに障害が発生したとどのような基準で判断しますか？
ランダムな読み取りエラーは、1つの壊れたディスクから発生する可能性がありますか？
ディスクが間違ったデータを送信したときに、レイドを検出しませんか？
スペアディスクのサイズが完全に一致していないときに、手動でディスクを故障としてマークするのは危険ですか？
私の意見では、MDレイドはディスクを追い出すことに関してあまりにも保守的です。私は常に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に動的に移行できるはずです。頭の上からはどうだかわかりませんが、それをググることはできます。
cronタスクでパリティの不一致チェックを開始することはかなり一般的です。 mdadmパッケージのインストール時にdebian 9がデフォルトでそれを行うので、システムのログに関連するレポートがあると確信しています。
さらに、システムのRAMが失敗した場合、それが主な理由である可能性があります