mdadm;以前は動作していましたが、「失敗」した後は、ディスクサイズのためアレイに参加できません。

抽象的な

Raid 5アレイが動作していますが、ボックスを再起動しましたが、mdadmは部品の1つを再組み立てできませんでした。

これはほんの一部なので、再同期するのは簡単だと思いました。しかし、今デバイスはアレイに参加するのに十分な大きさではないので、これはうまくいかないことがわかりました！ ？

初期レイド設定

悲しいことに、かなり複雑です。私は2つの3TBディスクと2つのリニアRAID（1TB + 2TBで構成）を組み合わせたRaid 5を持っています。ディスクを分割していません。つまり、RAIDは物理ディスクにまたがっています。振り返ってみると、これが初期失敗の原因であった可能性があります。

運命的な再起動後

mdadmは、スーパーブロックが存在しないと主張しながら、線形配列の1つを組み立てることを拒否します（mdadm --examineで両方を確認しても何も返されません）。さらに奇妙なことは、まだ分割可能な残留物が残っていることです。

この時点で最速の解決策は、線形配列を再作成し、それをより大きなraid5配列に追加してから再同期することです。したがって、私はこれらのパーティションテーブルエントリを削除することにしました。つまり、空き容量を確保するためにパーティションを分割しました。次に、2つのディスクにわたって線形アレイを作成しました。

# mdadm --create /dev/md2 --level=linear --raid-devices=2 /dev/sda /dev/sdc

しかし、配列に再度追加しようとすると

# mdadm --add /dev/md0 /dev/md2        
mdadm: /dev/md2 not large enough to join array

それでは、ディスクが縮小されたものと正確に推測しているのでしょうか？

カウントブロック

今ブロック計算をする時間だと思います！

線形配列の2つのコンポーネント：

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   1000204886016   /dev/sda
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   2000398934016   /dev/sdc

mdadmのリニアモードにオーバーヘッドがない場合、2つのサイズの合計は3TBドライブのうちの1つ（3000592982016）より大きくなります。しかしそれは真実ではない:

/proc/mdstat は、線形配列のサイズを必要なサイズより 120016 小さい 2930015024 として報告します。

# mdadm --detail /dev/md0 | grep Dev\ Size
Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)

しかし、これは...とても疑わしいです！再起動する前（以前のバージョンでは）、このラインアレイはより大きなアレイの一部でした！

私は何が起こったのか信じています。

再起動後、mdadmはアレイの一部が欠落していることを発見しました。最小のメンバーであるため、アレイデバイスのサイズは、次に最小のデバイスを満たすように自動的に大きくなります。

しかし、それは、合理的な行動のように聞こえません、そうですか？

代替案は、何らかの理由で、もはや最大サイズの線形アタックを生成しないことです。でも…それもちょっと面白かったです。

私は何をすべきか心配していました。

劣化した配列を縮小し、「破損した」線形配列を除き、--addと--growを再試行してください。しかし、これは実際にデバイスのサイズを変更しません。

正確に何が間違っているのか理解していないので、何かを急ぐ前にまずこの問題の原因が何であるかを理解したいと思います。