Mdadm--detailとmdadm--examineの出力に不一致が見られますが、その理由がわかりません。
この出力
mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Persistence : Superblock is persistent
これと矛盾しているようです。 (アレイ内のすべてのディスクで同じ)
mdadm --examine /dev/sdc2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to Host)
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
アレイはこのように作成されました。
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
5つの個別のドライブのそれぞれに、このようなパーティションがあります。
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 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
Disk identifier: 0x00057754
Device Boot Start End Blocks Id System
/dev/sdc1 2048 34815 16384 83 Linux
/dev/sdc2 34816 2930243583 1465104384 fd Linux raid autodetect
裏話
そのため、SATAコントローラーは私がサポートを提供するボックスで失敗しました。失敗は醜いものだったので、個々のドライブは一度に少しずつアレイから外れました。バックアップはありますが、実際に必要な頻度で実行されるわけではありません。可能であれば、回復しようとしているデータがいくつかあります。
追加のハードウェアを入手し、ドライブに再びアクセスできました。ドライブは正常に見え、アレイとファイルシステムをアクティブにしてマウントできます(読み取り専用モードを使用)。ファイルシステム上のいくつかのデータにアクセスしてそれをコピーしていますが、最新のデータをコピーしようとすると多くのエラーが発生します。
その最新のデータにアクセスしようとすると、以下のようなエラーが発生し、配列サイズの不一致が問題である可能性があると思います。
Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944
アレイを作成するためのコマンドラインは確かですか?私の推測では、これはホットスペアドライブを備えた「標準」の4ドライブraid10アレイであり、/ dev/sdc2の結果を説明します。
次の結果を教えてください。
cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )
これにより、どのドライブがホットスペアであったかを推測できる可能性があるため、アレイを適切に再構築できます。もちろん、3dinfluenceで述べられているように、アレイを再構成する前にデータを複製する必要があります。
編集:また、実行するのはおそらく時間の無駄ではありません:smartctl -a /dev/sdx
各ドライブで(エラーが報告されたかどうかを出力の最後で確認してください)、次にsmartcl -t long /dev/sdx
そして3または4時間後、5つのディスクをチェックするためのsmartctl -aは本当に問題ありません。 1つのディスクがエラーを報告している場合は、mdadmによって障害が検出された可能性があるため、mdadmがスペアドライブのスイッチをオンにしました(常に推測)
編集2:vgsが報告する場合:vgdisplayはAlloc PE/Size 3.00 TiB、Free PE/Size 421.08を表示しますこれは、PVが421Gで不思議に成長したことを意味します..私は私の場合を支持します:「謎」の成長はアレイの間違った構成です。配列の実際のサイズは3Tです。正しく組み立て直していないため、破損しています。正しく再構築するには、元の構成と、どのドライブがスペアドライブであったかを取得する必要があります。幸運を。
Ddを使用してドライブのクローンを作成できる場合は、それを実行します。元のドライブはできるだけ手つかずのままにしてください。
それならこれはヒップなものからのトータルシュートですが、そのような状況にあったら私が試してみたいものです。システム内のクローンドライブを使用して、を使用してすべてのRAIDメタデータを消去します。mdadm --zero-superblock /dev/sdx#
関連する各ドライブ。
次に、コマンドを使用してアレイを再作成します。mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 --assume-clean \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
これにより、RAIDレベルの問題がすべて解消されます。そこから、ファイルシステムを再マウントして、何が残っているかを確認できます。そして、これが機能しない場合は、ドライブのクローンを再作成して、別のことを試してください:)