web-dev-qa-db-ja.com

CentOS7で作成されたmdadmアレイは再起動後に消えます

以下のディスクとコマンドを使用してraid1を作成しました。

$ ls -l /dev/disk/by-id/ata-ST3000*
lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 -> ../../sdc
lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 -> ../../sda

$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1

関連情報をmdadm.confに追加しました。 ARRAY行に「mdadm--detail--scan >>/etc/mdadm.conf」を使用しました。

$ cat /etc/mdadm.conf
DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3
DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1
ARRAY /dev/md0 metadata=1.2 name=jaime.WORKGROUP:0 UUID=93f2cb73:2d124630:562f1dd9:bf189029
MAILADDR your@address

ファイルシステムを作成してマウントしました。

$ mkfs -t xfs /dev/md0
$ mount -t xfs /dev/md0 /data

再起動後、/ dev/md0は存在しなくなり、アレイをアセンブルできません。

$ mdadm --assemble /dev/md0 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1
mdadm: Cannot assemble mbr metadata on /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3
mdadm: /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 has no superblock - Assembly aborted



$ blkid
/dev/sda: PTTYPE="gpt"
/dev/sdb1: UUID="5c7d3f2b-c975-46a3-a116-e9fc156c1de5" TYPE="xfs"
/dev/sdb2: UUID="JhoqjI-N6R6-O9zt-Xumq-TnFX-OUCd-Lg9YHy" TYPE="LVM2_member"
/dev/sdc: PTTYPE="gpt"
/dev/mapper/centos-swap: UUID="3b882d4d-b900-4c59-9912-60a413699db4" TYPE="swap"
/dev/mapper/centos-root: UUID="08df953d-d4f4-4e83-bf4b-41f14a98a12e" TYPE="xfs"
/dev/mapper/centos-home: UUID="2358f723-5e7f-49ed-b207-f32fe34b1bbc" TYPE="xfs"
linuxcentosmdadm
2
uwsublime

この質問に出くわし、トラブルシューティング中に大いに役立ちました。しかし、どの答えも私の問題を解決できませんでした。

したがって、これは同じ問題を抱えている人に役立つかもしれません。私の場合、RedHat Linux7.2に2つのNVMEドライブがあります。

SELinuxにはnvmeに問題があり、mdadmがそれらを操作できません。

症状：

このスレッドの質問で説明されているように、ソフトウェアRAIDを作成します。再起動後、RAIDはなくなります。

  • /proc/mdstatは空で、/dev/md0 存在しません
  • mdadm --assemble --scanRAIDを起動します。

解決策：

私の場合、selinuxを無効にしました。これがすべてのシステムで可能であるとは限らないことを私は知っています。しかし、多分あなたは私の投稿から正しい方向に進んでいます。

1
ora-600

理論的には、「ベアドライブ」（パーティション化されていない）からレイドを作成できますが、ディスクがmdドライブではなくgptパーティション化されたものとして表示されていることに気付きました。一般に、ディスクをパーティション分割してから、mdアレイでパーティションを使用することで、より良い成功/安定性が得られました。

パーティションテーブルを作成して、パーティションタイプをlinux raid autodetect（正しく思い出せばfdiskのfd）に設定してみます。次に、アレイを再作成します。

また、mdadm.confを使用しなかった場合は、より良い成功が得られることがわかりました。最新バージョンのmdツールは、関連するパーティションのスーパーブロックから必要なすべての情報を取得します。

1
Jim Kusznir

すべての皆さんのために、私は私のために働く回避策を見つけました..これはあなたたちを助けるかもしれません..ここにあります：

システムが起動時または起動時にmdadm.confファイルを読み取っていないため、レイドマウントが消えます。それで、私がしたことは、以下のコマンドを含むように/etc/rc.d/rc.localファイルを編集したことです。

sleep 10
mdadm --assemble --scan
sleep 10
mount -a

これで、システムを再起動するたびに、このファイルが読み取られ、そこに記載されているコマンドが実行され、レイドマウントがマウントされます。

1
user3416955

通常の警告が適用されます。データがバックアップされていることを確認してください。私はデータの損失について責任を負いません。これは私のために働いた。意味のあるデータを配列に配置する前に、必ず配列をテストしてください。再起動やデバイス名の変更などに耐えられることを確認してください。

さて、私がしたことに移りましょう。

私は今日同じ問題に遭遇しました。いくつかの検索を行った後、私はこれを修正し、安定したレイドデバイスを入手することができました。

アレイに使用していた2つのディスクで、RAIDデバイスを作成する前にgdiskを使用してパーティションを作成しました。 gdiskを使用してパーティションを削除しましたが、アレイを作成すると、以下の情報メッセージが表示されました。

mdadm: partition table exists on /dev/disk/by-id/ata-ST4000VN000-1H4168_Z30254QX but will be lost or meaningless after creating array

再起動したときにこのメッセージが表示されるたびに、アレイが失われます。

上記のJimKの提案を使用して、各ドライブにLinuxRAIDパーティションを作成すると思いました。これは機能しましたが、同期速度はrawドライブの145MB/sからパーティションドライブの35MB/sになりました。おそらくチューニングパラメータで遊ぶことができたかもしれませんが、なぜそれをする必要がありますか？

ドライブパーティションテーブルを削除する方法を見つけようと探求しました。

修正...

まず、レイドデバイスが停止していることを確認してから、ドライブのレイド署名を削除します。

mdadm --stop /dev/md<number> 
mdadm --zero-superblock /dev/sd<x> (do this for all your raid disks)

Blkidを実行して、レイドデバイスのいずれかが表示されるかどうかを確認します。もしそうなら。

実行：

dd if=/dev/zero of=/dev/sd<x> bs=512 count=1

これにより、パーティションテーブルが削除されることが期待されます。 blkidを再度実行して、レイドデバイスに使用されているディスクがリストされていないことを確認します。

私の場合、gptのLVMラベルは1つのディスクにバックアップされていました。 lvremove、vgremove、最後にpvremoveを使用してこれをクリーンアップしました。

今回はblkidがきれいに走りました。

ただし、アレイを再度作成しようとすると、既存のRAIDデバイスに関するエラーが発生したため、もう一度ddを実行しました。この後、上記のような通知なしにアレイが作成されました。

アレイを元の状態で再作成し、SDの代わりにdisk/by-idを使用しました。アレイが再作成されると、アレイ上に作成したテストパーティションは元の状態に戻りました。

アレイは再起動後も存続し、アレイが最初に作成されたときから/ dev/sdに変更されます。

0
xtree

blkidの出力は、問題を示しています。mdデバイスを作成したときにドライブがクリーンでなく、古い情報が混乱を招いています。

パーティションテーブルなしでこれらを作成したことを考えると、blkidがsdaとsdcのPTTYPE = "gpt"を報告するという事実が問題です。

保存する必要のあるデータが（まだ）ドライブにない場合は、「dd」を使用してGPTパーティションテーブルを消去できます。

$ Sudo dd if =/dev/zero of =/dev/sda bs = 1M count = 10

これにより、/dev/sdaの最初の10メガバイトがゼロになります。 /dev/sdcについて繰り返します。その後、アレイを再作成すると、起動時に/dev/md0が表示されます。

0
samson

私はそれが古い投稿であることを知っています、しかし私はこの問題に苦労していました、そしてこれは私の結果です：

私のディスクは「凍結」されていました-Seagateディスク。コマンドを入力して、同じ問題があるかどうかを確認できます。

hdparm -I /dev/sdb

示した：

Security: 
Master password revision code = 65534
    supported
not enabled
not locked
    frozen
not expired: security count
    supported: enhanced erase

この設定を変更できませんでした。ディスクは通常のパーティションで正常に動作しましたが、Linux RAIDとしてフォーマットしていると、パーティションテーブルが失われ、再起動後に「空」になりました。

デバイスではなく、パーティションにレイドを作成しました。

mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

そして今、それらは再起動後に問題なく、すべてが期待どおりに機能します。

0
Kamil Blixiński

タイプfd（Linux RAID自動検出）でディスクパーティションをフォーマットするためのより良い方法のようですが、fdiskのアライメントメッセージに注意してください！私はそれらの警告を受け取り、パーティションを作成し、fdiskを使用してタイプ「fd」に設定するための別のツールでそれらを解決しました。次に、実行したとおりに実行すると、起動時にRAIDデバイスが自動的に形成されます。/etc/fstabにエントリがあると、マウントされることもあります...

1つの注意点：/etc/mdadm.confを使用すると、RHEL73.10.0-514.6.1.el7.x86_6システムが破壊されました。

0
Spruance