約 9 か月前にインストールした 2 台のまったく新しい同一のサーバーで、同じ問題を発見しました。システムがディスクを読み取り専用としてマークしていたため、両方のディスクに書き込むことができませんでした。ログには、両方のディスクに何らかのディスク エラーがあったことが示されていました。
それぞれのサーバーで複数のゲストでKVMを実行していることに注意してください。ゲストはすべて正常に動作していましたが、問題はKVMホストにありました。これはおそらく重要ではありませんが、関係があるかもしれません。両方のシステムには2つのドライブソフトウェア RAID1 と LVM が最上位にあります。各 KVM ゲストには独自の LVM パーティションもあります。
を見ると、両方のシステムで RAID1 アレイの劣化が示されていました/proc/mdstat。
そこでシステムの 1 つを再起動すると、手動で実行する必要があると表示されましたfsck。そのため、手動で実行しました。問題は解決したようで、再起動するとシステムが正常に起動しました。同じプロセスが 2 番目のサーバーでも機能しました。
次に、mdadm --manage /dev/md0 --add /dev/sdb1故障したドライブをアレイに戻しました。これは両方のサーバーで正常に機能しました。その後 1 時間ほど、 を見ると、/proc/mdstatドライブの同期が進行していることが示されました。約 1 時間後、1 つのシステムが完了し、/proc/mdstatですべてが正常に動作していることが示されました[UU]。
しかし、もう一方のシステムでは、約 1.5 時間後にシステム負荷が急上昇し、何も応答しなくなりました。数分後、すべてが回復しました。しかし、/proc/mdstat今見ると次のようになります。
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
ご覧のとおり、同期されなくなったようです。完了率、残り時間などは表示されなくなりました。ただし、実行するとmdadm --detail /dev/md0次のように表示されます。
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
一番下の行は、スペアが再構築中であることを示しているようです。なぜスペアなのでしょうか? システムは両方のデバイスがクリーンであると報告しています。何時間もこの状態が続いています。ドライブは小型で高速な 300GB 10K RPM VelociRaptors なので、もう同期されていると思います。再度追加しようとすると、デバイスがビジー状態であると表示されます。
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
「正常な」サーバー上で dmesg を実行すると、最後に次の内容が表示されます。
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
「悪い」サーバーでは、最後の 4 行が何百回も繰り返されます。「良い」サーバーでは、1 回だけ表示されます。
ドライブはまだ同期していますか? この「再構築」は完了しますか? もう少し辛抱する必要がありますか? そうでない場合、今何をすべきですか?
アップデート：
再起動したら、ドライブが再び同期し始めました。約 2 時間後、上記と同じことが起こりました (まだ [_U] が表示されます)。ただし、RAID1 conf のプリントアウト チャンクがすべて消費される前に、dmesg ログを確認することができました。
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
したがって、私が尋ねるべき質問は、「RAID セット内のスペア ディスクで fsck を実行するにはどうすればよいでしょうか?」ということかもしれません。
答え1
故障したドライブを実際に交換したかどうかは不明です。故障したドライブを再度追加した場合、症状は納得できると思いますが、その場合、ドライブがロックアップしている可能性が高くなります。故障したドライブを再度追加した場合、/var/log/messages または dmesg にその後のエラーは表示されますか?
(ちなみに、故障したドライブを RAID アレイに再度追加することは絶対にお勧めしません。故障によってプラッター上のデータが破損した場合、それをアレイに戻すと、再同期によって破損したファイルがディスク上に残り、次にファイルを読み取るときに、どのディスクが最初に応答するかによって、正常なデータを取得するか不良データを取得するかが運任せになります。私は実際にこのようなことが起こるのを見たことがあります。)
答え2
mdadm --details を使用すると、再構築中のドライブがスペアとしてリストされます。再構築が完了すると、スペアとして表示されなくなります。
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
最初の行は、再割り当てに失敗し、データが読み取られなかったことを示しています。次の 3 行は、データを読み取れなかったことを指摘し、読み取り不可能なセクターをリストします。
Rodger が指摘したように、ドライブが不良なので、再度追加しないでください。故障したドライブを再度追加するのは決して良い考えではありません。ドライブを取り外して交換してください。必要な場合は、故障したドライブの診断を実行してください。ただし、ドライブを取り外して交換した後でのみ実行してください。
答え3
まず、ログ ファイルに記録される読み取りエラーをスローしているディスクをすべて削除します。これは、不良ブロックの再配置が失敗したか、ドライブが故障しそうになっていることを意味します。
データを救出するには、次のようなLinuxレスキューCDを使用することをお勧めします。http://ubuntu-rescue-remix.org/ddrescueを使用します。これは新しいディスクのパーティションにイメージコピーを実行し、パーティションの回復を何度も再試行します。USBドライブまたは別のパーティションをマウントします
mkdir /tmp/x && マウント /dev/sdd1 /tmp/x
ddrescue ログ ファイルを保持します。その後、ddrescue を停止し (ctrl-C)、後で同じ時点から再起動することができます。
新しいディスクのパーティションを古いディスクより少し大きくします。ディスク全体を使用する必要はありません。
カーネルブートパラメータとして「nodmraid」を指定してレスキューCDを起動します。UbuntuライブCDを使用している場合は、RAIDとLVMをインストールします。
apt-get install mdadm lvm2 gddrescue
これを機能させるにはインターネットに接続している必要があります)。それ以外の場合は、ddrescue ステップに Ubuntu レスキュー CD を使用します。私は、ddrescue 実行用のレスキュー CD と、grub および fsck 作業用のライブ CD を交換しました。
/dev/sdbが故障したソースディスク、/dev/sdxが新しいディスク、/mnt/xがUSBキーまたはマウントされた別のディスクのパーティションであると仮定します。必要ddrescue ログ ファイルです。ddrescue の進行状況を追跡し、中断できるようにします。
に従ってhttp://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX イメージファイル /mnt/x/logfile
それから
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
それから
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
1 つのセクターを回復するのに何時間もかかる場合は、恐れずに Ctrl + C キーを押してプロセスを終了してください。次のステップに進んでください (ステップ 1 は必ず成功するはずです)。最後のステップでは、使用可能なデータの最後のかけらまで回復しようとします。
また、
mdadm --create /dev/md99 --level-1 --raid-devices=2 /dev/sdX がありません
新しいディスクを使用して新しい RAID アレイを作成するには、パーティションに新しい RAID スーパーブロックを書き込みます (パーティションの最後の 64K から 128K 内)。
故障した古いディスク /dev/sdb をシステムから削除し、Linux から見えないようにします。
ソース RAID ディスクをアクセス可能にします。Ubuntu のレスキュー CD で問題が発生したため、カーネルを起動するカーネルに「nodmraid」パラメータを使用する必要があるかもしれません。そのため、Ubuntu ライブ CD (10.4) では nodmraid が F6 オプションにあります。
mdadm --assemble /dev/md99 /dev/sdX
次に、fsck を実行するか、md99 RAID アレイ上のデータに対して必要なチェックを実行します (vgscan を使用した後、チェックを実行する LVM LV を確認できました)。mythtv には XFS を使用していますが、xfs_check コマンドによってシステムがクラッシュしましたが、xfs_repair は正常でした。
新しい/dev/sdXから/bootディレクトリをマウントします
/dev/mapper/my_vg/root_lv /tmp/x をマウントします。
次に、新しい /dev/sdX RAID ディスクに新しい GRUB ブート レコードを配置します (RAID からブートする場合のみ)。
grub-setup -d /tmp/x/boot/grub /dev/sdX
これで、(ほぼ) 起動可能な RAID アレイができました。GRUB 自体を使用してセットアップすることも、dd を使用して /dev/sdb の最初の 446 バイトを /dev/sdX にコピーすることもできます。最初の 446 バイトのみで、1 番目のセクターの残りはパーティション テーブルです。それ以上コピーすると、ひどく混乱します。パーティション /dev/sdX1 (たとえば) の最初のセクターに対しても同じことを行う必要があるかもしれません。上書きするセクターはすべて、dd を使用してバックアップしてください。
grub2 を使用していて RAID から起動している場合、RAID アレイの UUID が変更されているため、起動が失敗します。起動コマンド ライン (Grub 起動パネルの e) を編集して、splash と quiet を削除し、何が起きているかを確認します。その後、起動に失敗すると、initramfs に残ります。
mdadm --assemble /dev/md99 /dev/sdX
次に、/proc/mdstat をチェックして、アレイが存在することを確認します。アレイが存在する場合は、単に「終了」します。GRUB ブート スタンザが正常に動作するはずです (私の場合は LVM を使用するように設定されていたため、RAID デバイスが存在する場合は RAID デバイス上の LV が見つかり、LV が検索されました)。起動したら、ほぼ完了です。
initrdイメージファイル（gzip圧縮されたcpioファイル）には、起動プロセス中に使用されるmdadm.confのコピーが含まれており、起動プロセス中に/etc/mdadm/mdamdm.confとして表示および編集できます。システムを正常に起動できる場合は、initramfsを次のように更新するだけです。
アップデート-initramfs -u
mdadm.confファイルのUUIDが一致しないためにシステムを起動できない場合
別の方法 (Grub、レスキュー、実際のブート) でブートすると、宛先デバイス /dev/sdX が /dev/sdY として表示される場合があることに注意してください。
ちなみに、RAID5 を使用していて、ブロック アライメントに本当に興味がない限り、RAID アレイにはパーティションを使用することをお勧めします。ディスク全体を使用する必要はありません (特に、1 TB ディスクを 2 TB ディスクに交換する場合)。後で別のパーティションと 2 番目の RAID アレイを追加して、2 TB 全体を使用することもできます。
ふう！完了！