FuntooでのRAID1のセットアップ
要するに
ガイドに従って GNU/LinuxでRAID1をセットアップする方法 、RAID 1をセットアップしました。さまざまな方法でRAIDアレイの有効性をチェックすることは、正常であるように見えました。
ただし、システムを再起動した後、RAIDアレイは機能していませんでした。問題のパーティションは、/etc/fstabの指示どおりにマウントされませんでした。アレイの組み立ては手動で行われ、データは失われていません。
新しく追加された内部/外部ディスクは、ディスクデバイス名の変更（システムによってディスクの名前がsddからsdeに変更されるなど）につながるため、それを受け入れるようになりました。それはこの名前を変える事実に関連した問題でした。ただし、RAIDアレイは（また）一意のUUIDを使用して構築されるため、これは関係ありません。
実際の質問は、ブートプロセス中にアレイがアセンブルに失敗するのはなぜですか？または、オペレーティングシステムであるFuntooのブートスクリプトは何ですか？ mdadm -assembleプロセスに関して、すべてのプロットが実行されますか？
長い話
上記のステップバイステップガイドに従って、Funtooの下にRAID1をセットアップしました。 RAID 1アレイの有効性のチェックは、主にmdadmツール自体の機能を使用していくつかの方法で行われました。
具体的には、配列の詳細は、mdadmツールと-Dフラグを使用して取得されました。アレイに関連するディスクは、-Eフラグを使用して調べられました。それぞれの構成ファイルmdadm.confは、正しい命令（つまり、どのmdデバイス、そのUUIDなど）が含まれている場合に簡単に読み取ることができます。最後に、ファイル/proc/mdadmを監視することは、両方のディスクがアクティブで「同期」されていることを確認するために重要でした。
以下は、直面している状況に関するさらに詳細な情報です。
mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 1953382208 (1862.89 GiB 2000.26 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Thu Jul 18 10:33:37 2013
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : Resilience:0 (local to Host Resilience)
UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Events : 6455
Number Major Minor RaidDevice State
2 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
コマンド履歴から、私は次のことをしました
# trying to follow the guide -- various tests...
...
979 18.Jul.13 [ 00:09:07 ] mdadm --zero-superblock /dev/sdd1
980 18.Jul.13 [ 00:09:17 ] mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sdd1
990 18.Jul.13 [ 00:15:58 ] mdadm --examine --scan
# creating/checking the configuration file
992 18.Jul.13 [ 00:16:17 ] cat /etc/mdadm.conf
993 18.Jul.13 [ 00:16:33 ] mdadm --examine --scan | tee /etc/mdadm.conf
994 18.Jul.13 [ 00:16:35 ] cat /etc/mdadm.conf
# after some faulty attempts, finally it goes
997 18.Jul.13 [ 00:24:45 ] mdadm --stop /dev/md0
998 18.Jul.13 [ 00:24:54 ] mdadm --zero-superblock /dev/sdd1
999 18.Jul.13 [ 00:25:04 ] mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sdd1
1005 18.Jul.13 [ 00:26:39 ] mdadm --examine --scan | Sudo tee /etc/mdadm.conf
1046 18.Jul.13 [ 03:42:57 ] mdadm --add /dev/md0 /dev/sdc1
構成ファイル/etc/mdadm.confは次のように読み取ります。
ARRAY /dev/md/0 metadata=1.2 UUID=73bf29ca:89bff887:79a26531:b9733d7a name=Resilience:0
/proc/mdadmからわかるように、すべて正常に動作します。
Personalities : [raid6] [raid5] [raid4] [raid1] [raid0] [raid10] [linear] [multipath]
md0 : active raid1 sdc1[2] sdd1[1]
1953382208 blocks super 1.2 [2/2] [UU]
unused devices: <none>
その後、ディスクが同期され、アクセスは正常でした。システムをシャットダウンし、外部（USB経由）または内部に別のディスクを追加し、システムを再起動すると、RAID1が機能しなくなりました。その理由は、私が間違っていなければ、ディスクデバイス番号の変更です。
この例では、以前のsdd1はsde1になり、sdd1は、システムを起動する前に接続された「新しい」内部ディスクまたは外部USB HDDによって予約され、自動的にマウントされるように指示されました。
他のすべてのディスクを取り外し、アレイを停止して再組み立てすることにより、「失敗した」アレイを「回復」するのは非常に簡単でした。試行中に発行され、最後にARRAYを正常に取り戻すコマンドのいくつかは次のとおりです。
# booting and unsuccessfully trying to add the "missing" disk
1091 18.Jul.13 [ 10:22:53 ] mdadm --add /dev/md0 /dev/sdc1
1092 18.Jul.13 [ 10:28:26 ] mdadm --assemble /dev/md0 --scan
1093 18.Jul.13 [ 10:28:39 ] mdadm --assemble /dev/md0 --scan --force
1095 18.Jul.13 [ 10:30:36 ] mdadm --detail /dev/md0
# reading about `mdadm`, trying to "stop", incomplete command though
1096 18.Jul.13 [ 10:30:45 ] mdadm stop
1097 18.Jul.13 [ 10:31:12 ] mdadm --examine /dev/sdd
1098 18.Jul.13 [ 10:31:16 ] mdadm --examine /dev/sdd1
1099 18.Jul.13 [ 10:31:20 ] mdadm --examine /dev/sdc
1100 18.Jul.13 [ 10:31:21 ] mdadm --examine /dev/sdc1
# reading again, stop it -- the right way
1101 18.Jul.13 [ 10:33:19 ] mdadm --stop /dev/md0
# assemble & check
1102 18.Jul.13 [ 10:33:25 ] mdadm --assemble /dev/md0 --scan
1111 18.Jul.13 [ 10:34:17 ] mdadm --examine /dev/sd[cd]1
# does the Array have a UUID?
1112 18.Jul.13 [ 10:37:36 ] UUID=$(mdadm -E /dev/sdd1|Perl -ne '/Array UUID : (\S+)/ and print $1')
# below, learning how to report on the Array
1115 18.Jul.13 [ 10:42:26 ] mdadm -D /dev/md0
1116 18.Jul.13 [ 10:45:08 ] mdadm --examine /dev/sd[cd]1 >> raid.status
1197 18.Jul.13 [ 13:16:59 ] mdadm --detail /dev/md0
1198 18.Jul.13 [ 13:17:29 ] mdadm --examine /dev/sd[cd]1
1199 18.Jul.13 [ 13:17:41 ] mdadm --help
1200 18.Jul.13 [ 13:18:41 ] mdadm --monitor /dev/md0
1201 18.Jul.13 [ 13:18:53 ] mdadm --misc /dev/md0
ただし、マウントがUUIDやLABELに基づいている場合は、これが発生せず、他のディスク/パーティションと同様に安全に再生できると思います。
/etc/fstabの対応するエントリは（note、オプションnosuid,nodev）をスキップしました
/dev/md0 geo xfs defaults 0 2
sdc1の詳細、mdadm -E /dev/sdc1からの出力
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Name : Resilience:0 (local to Host Resilience)
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 3906764416 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5552ba2d:8d79c88f:c995d052:cef0aa03
Update Time : Fri Jul 19 11:14:19 2013
Checksum : 385183dd - correct
Events : 6455
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
問題のパーティションの詳細
sdd1の詳細、mdadm -E /dev/sdd1からの出力
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Name : Resilience:0 (local to Host Resilience)
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 3906764416 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 076acfd8:af184e75:f83ce3ae:8e778ba0
Update Time : Fri Jul 19 11:14:19 2013
Checksum : c1df68a0 - correct
Events : 6455
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing)
もう一度「新しい」内部ディスクを追加して再起動した後、同じ問題が発生します。
mdadm -E /dev/sdd1レポート
mdadm: No md superblock detected on /dev/sdd1.
mdadm -E /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Name : Resilience:0 (local to Host Resilience)
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 3906764416 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 076acfd8:af184e75:f83ce3ae:8e778ba0
Update Time : Fri Jul 19 11:34:47 2013
Checksum : c1df6d6c - correct
Events : 6455
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing)
およびmdadm --detail /dev/md0
mdadm: md device /dev/md0 does not appear to be active.
cat /proc/mdstatが読み取りている間
Personalities : [raid6] [raid5] [raid4] [raid1] [raid0] [raid10] [linear] [multipath]
md0 : inactive sde1[1](S)
1953382400 blocks super 1.2
unused devices: <none>
Gilles 'の観察によると、この時点で、報告されたブロック（1953382400）は、上記のようにArray Size : 1953382208について報告されたものと一致しないことに注意してください（または未満）。明らかに、ここで問題が発生しました。
mdadm -Evvvvsの（部分的な）出力は
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Name : Resilience:0 (local to Host Resilience)
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 3906764416 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 076acfd8:af184e75:f83ce3ae:8e778ba0
Update Time : Fri Jul 19 11:34:47 2013
Checksum : c1df6d6c - correct
Events : 6455
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing)
/dev/sde:
MBR Magic : aa55
Partition[0] : 3907026944 sectors at 2048 (type fd)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 73bf29ca:89bff887:79a26531:b9733d7a
Name : Resilience:0 (local to Host Resilience)
Creation Time : Thu Jul 18 00:25:05 2013
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 3906764800 (1862.89 GiB 2000.26 GB)
Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
Used Dev Size : 3906764416 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5552ba2d:8d79c88f:c995d052:cef0aa03
Update Time : Fri Jul 19 11:34:47 2013
Checksum : 385188a9 - correct
Events : 6455
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 3907026944 sectors at 2048 (type fd)
前のfdisk -lで確認 sdcおよびsddディスクs、 です今です sdbおよびsde（m 残りのドライブのサイズからのディスク）。 「それ」はまだ見ている/のためのようです sdc1sdd1？
コメントセクションで見つかった提案に従って、詳細を追加しました。
コメントのderobertの提案に従って、ARRAYは停止し、正常に再アセンブルされました。
# stop it!
mdadm --stop /dev/md0
mdadm: stopped /dev/md0
# re-assemble -- looks good!
mdadm --assemble -v --scan
mdadm: looking for devices for /dev/md/0
mdadm: no RAID superblock on /dev/sdf1
mdadm: no RAID superblock on /dev/sdf
mdadm: no RAID superblock on /dev/sde
mdadm: no RAID superblock on /dev/sdd1
mdadm: no RAID superblock on /dev/sdd
mdadm: no RAID superblock on /dev/sdc
mdadm: no RAID superblock on /dev/sdb
mdadm: no RAID superblock on /dev/sda6
mdadm: no RAID superblock on /dev/sda5
mdadm: no RAID superblock on /dev/sda4
mdadm: no RAID superblock on /dev/sda3
mdadm: no RAID superblock on /dev/sda2
mdadm: no RAID superblock on /dev/sda1
mdadm: no RAID superblock on /dev/sda
mdadm: /dev/sde1 is identified as a member of /dev/md/0, slot 1.
mdadm: /dev/sdc1 is identified as a member of /dev/md/0, slot 0.
mdadm: added /dev/sde1 to /dev/md/0 as 1
mdadm: added /dev/sdc1 to /dev/md/0 as 0
mdadm: /dev/md/0 has been started with 2 drives.
# double-check
mdadm --detail --scan
ARRAY /dev/md/0 metadata=1.2 name=Resilience:0 UUID=73bf29ca:89bff887:79a26531:b9733d7a
新しい質問、これはどのように修正されますか データを失うことなくそれ？コメントの議論と推奨事項によると、それはブートプロセスに関連していますか？ 問題のマウントポイントへのアクセス許可はおそらく？
mdadmはブートサービスとして登録されていません。それを追加して再起動しても、問題は修正されませんでした。 dmesgの失敗箇所に関する詳細は、おそらく興味深いものです。
[ 25.356947] md: raid6 personality registered for level 6
[ 25.356952] md: raid5 personality registered for level 5
[ 25.356955] md: raid4 personality registered for level 4
[ 25.383630] md: raid1 personality registered for level 1
[ 25.677100] md: raid0 personality registered for level 0
[ 26.134282] md: raid10 personality registered for level 10
[ 26.257855] md: linear personality registered for level -1
[ 26.382152] md: multipath personality registered for level -4
[ 41.986222] md: bind<sde1>
[ 44.274346] XFS (md0): SB buffer read failed
[ 55.028598] ata7: sas eh calling libata cmd error handler
[ 55.028615] ata7.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0
[ 55.046186] ata7: sas eh calling libata cmd error handler
[ 55.046209] ata7.00: cmd ef/c2:00:00:00:00/00:00:00:00:00/40 tag 0
[ 55.278378] ata8: sas eh calling libata cmd error handler
[ 55.278406] ata8.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0
[ 55.349235] ata8: sas eh calling libata cmd error handler
[ 55.349290] ata8.00: cmd ef/c2:00:00:00:00/00:00:00:00:00/40 tag 0
[ 105.854112] XFS (md0): SB buffer read failed
問題のXFSパーティションをさらにチェックするsde1
xfs_check /dev/sde1 xfs_check: /dev/sde1 is not a valid XFS filesystem (unexpected SB magic number 0x00000000) xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. xfs_check: read failed: Invalid argument cache_node_purge: refcount was 1, not zero (node=0x22a64a0) xfs_check: cannot read root inode (22) bad superblock magic number 0, giving up
問題のXFSパーティションが正常ではないことが判明しました。
XFSファイルシステムは、不可能ではありませんが、ここでの問題の根本ではない可能性があります。 RAIDアレイの一部であるパーティションは、GillesのコメントによるとXFSファイルシステムではありません！ファイルシステムはオフセットから始まり、最初にRAIDヘッダーがあります。
質問
はじめに
RAID 1アレイを「ロック」して、ディスクデバイス名とは関係なく特定のディスク/パーティションでのみ機能することは可能ですか？
たとえば、ディスクデバイス名の変更の影響を受けないように、
/etc/fstabでアレイのUUIDを使用するだけで十分でしょうか？
問題を再調査した後
- Funtooの起動プロセスのどの段階でRAIDアレイの組み立てが試みられますか？どのくらい正確に？どこで変更/調整できますか？
OK-ボックスで何が問題になっているのか正確にはわかりませんが、トラブルシューティングに役立てるために、これがどのように機能するかについての簡単な要約はどうでしょうか想定。
永続的なスーパーブロック（非常に適切なデフォルト、およびそれを行った方法）を使用して配列を作成すると、mdadmは各ディスクにさまざまなメタデータを格納します。そのメタデータには、アレイUUID、アレイ名、およびスロット番号が含まれています。各ディスクには同じUUIDと名前が格納されます。スロット番号はディスクごとに異なります。 （メタデータを表示する場合は、mdadm -Eを使用してください）
起動時にアレイを組み立てる方法は3つあります。
- カーネルはそれを行うことができます。これは、0xFD自動検出パーティションタイプが行ったことです。この方法は推奨されません。
- ディストリビューションのスクリプトは、インクリメンタルアセンブリを使用して、
udevの一部としてそれを実行し、デバイスが表示されたらmdadmに渡します。これが最新の方法です。正しく動作すると、USBなどのあらゆる種類の非同期プローブデバイスをクルーグなしで処理します。 - すべてのデバイスが認識されたと信じられた後、ディストリビューションのスクリプトは
mdadm --assemble --scanを呼び出します。 USBなどにはKlugesが必要です（基本的に、デバイスノードが作成されたことを確認するためのスリープ）。このモードでは、mdadmは（デフォルトで）/proc/partitionsをチェックしてシステム上のすべてのブロックデバイスを見つけ、それぞれをスキャンしてスーパーブロックを探します。
Distroスクリプトは、initramfs以降でこれを実行できます。または、一部の配列はinitramfs（ルートファイルシステムを取得するために必要な配列）から実行され、他の配列はブートの後半で実行される場合があります。
それがどのように行われるかに関係なく、mdadmはUUID、名前、およびスロット番号を調べてデバイスを照合します。 2ディスクアレイの＃0と＃1を見つける必要があります。実際にはどのデバイスであるかは関係ありません（デフォルトでは、mdadm.confで気になるように構成できます）
RAID 1アレイを「ロック」して、ディスクデバイス名とは関係なく特定のディスク/パーティションでのみ機能するようにすることはできますか？
これを実現するには、/dev/disk/by-*の下のエイリアスを使用できるはずです。 /dev/disk/by-id/*をお勧めします。これらは、物理ディスク上ですぐに表示できる情報に直接マップされますが、どのディレクトリにも、シナリオで役立つシンボリックリンクが含まれている必要があります。どちらを使用するかは、主に好みの問題です。
たとえば、私のシステムでは、/ dev/disk/by-id/scsi-SATA_ST31000340NS_9QJ26FT9-part1は/ dev/sdb1にマップされます。つまり、bus、model、serial、およびpartitionの番号で、問題のパーティションにつながります。アレイ内のドライブに障害が発生した場合は、質問でmdadmコマンドのようなものを使用して、どの物理ドライブが原因であるかを明確に判断できます。
たとえば、ディスクデバイス名の変更の影響を受けないように、/ etc/fstabでアレイのUUIDを使用するだけで十分でしょうか？
私はMDRAIDにあまり詳しくありませんが、それはアレイ全体への参照だけに影響を与えるのではないでしょうか。/dev/md0が突然/ dev/md1として表示されることを心配している場合は、配列自体への固定参照を提供する他の方法があるでしょうか。