☰

プログラムで実行すると、mdadmは一貫性がありません。

tag-icon • tag-icon arch-linux sudo php mdadm
プログラムで実行すると、mdadmは一貫性がありません。

アップデート＃1：

私は追加のテストを実行し、シェルスクリプト（.sh、＃！/ bin / bash）とphpのcliによって実行されるphpスクリプトを作成しました。

バッシュが動作します。

問題を引き起こすのは、ApacheのHTTPコンテキストではなくPHP自体のようです。php raider.php単にルートシェルで実行すると、最初に述べたのと同じ2つの問題が発生するためです。

WebOSでデバイスを作成しています。 WebOSにはオペレーティングシステム（ルート）へのアクセスが必要なため、Apacheでホストされていますhttp:http。 sudoersは、NOPASSWDを使用してALLを許可するように設定されていますhttp。

ルートとして実行されるプロセスをトレーニングしないでください。環境が制御され、2年間で40以上のデバイスが出荷され、問題は報告されていません。

phpproc_openコマンドはHTTPリクエストコンテキスト（Apacheの場合はmod_php5）によって実行されます。

を除くすべてのコマンドが正しく機能しているようですmdadm --create。アレイを作成しようとすると、作成しようとしているRAIDレベルに応じてランダムな結果が表示されます。

前にも一つありました。名前空間の問題しかし、もはやそうではありません。一部のOSのアップデート後に問題が発生し始めました（正確にいつであるかはわかりません。以前のバージョンのWebOSが機能しなかったため、最近問題が発生し、明らかに修正が必要でした。最新バージョンもあります。コマンドの実行周期が異なります。

mdadm_udev起動時にRAIDをアセンブルするためにinitramfsフックを使用しています。 RAIDのメタデータを基準に正しく組み立てたようで空白にし/etc/mdadm.confました。mdadm_udevしかし、唯一の問題はそれらを組み立てるときです<hostname>:<raidname>。

上記の問題のために使用していますが、ユーザーがmdadm --create /dev/md/<hostname>:stoneshare ...誰であるかにかかわらず（root以外のユーザーがsudoとして実行して成功した場合）、CLIで正しく実行されているように見えますが、HTTPコンテキストで実行すると問題があります。

シナリオ＃1、RAID0：

<?php

$command = sprintf('sudo mdadm --create /dev/md/%s:stoneshare --level 0 --raid-devices 2 /dev/sdb1 /dev/sdc1');
proc_open($command, /* ... */, /* ... */);

/dev/md127ただし、RAIDを有効にして次のシンボリックリンクを使用してCLIを使用して上記のスクリプトを/dev/md/<hostname>:<sharename>実行すると、RAIDが作成されます/dev/md127。

[root@stone ~]# mdadm --detail --scan
ARRAY /dev/md127 metadata=1.2 name=stone:stoneshare UUID=7329e458:96be442a:84f616d8:fd4ba42e

[root@stone ~]# ls -la /dev/md*
brw-rw---- 1 root disk 9, 127 Jul 30 11:48 /dev/md127

シナリオ＃2、RAID1：

<?php

$command = sprintf('sudo mdadm --create /dev/md/%s:stoneshare --level 1 --assume-clean --raid-devices 2 /dev/sdb1 /dev/sdc1');
proc_open($command, /* ... */, /* ... */);

確認する：

[root@stone ~]# mdadm --detail --scan
ARRAY /dev/md/stone:stoneshare metadata=1.2 name=stone:stoneshare UUID=7329e458:96be442a:84f616d8:fd4ba42e

[root@stone ~]# ls -la /dev/md*
brw-rw---- 1 root disk 9, 127 Jul 30 11:48 /dev/md127

/dev/md:
total 0
drwxr-xr-x  2 root root   60 Jul 30 12:17 .
drwxr-xr-x 19 root root 3080 Jul 30 12:17 ..
lrwxrwxrwx  1 root root   10 Jul 30 12:17 stone:stoneshare -> /dev/md127

奇妙なことに、シンボリックリンクは作成されましたが、他の問題があります。つまり、RAID作成時にランダム/dev/sdb1または自動的にエラーとして表示されるということです。/dev/sdc1RAIDが作成され開始されましたが、1つのドライブで実行されています。場合によっては、両方のドライブが障害としてマークされず、RAIDがまったく問題なく作成されることがあります。

私が見つけた機器の故障に関する情報を選別しました。

[root@stone ~]# journalctl -xb
Jul 30 11:39:43 stone kernel: md: bind<sdb1>
Jul 30 11:39:43 stone kernel: md: bind<sdc1>
Jul 30 11:39:43 stone kernel: md/raid1:md127: active with 2 out of 2 mirrors
Jul 30 11:39:43 stone kernel: created bitmap (8 pages) for device md127
Jul 30 11:39:43 stone kernel: md127: bitmap initialized from disk: read 1 pages, set 14903 of 14903 bits
Jul 30 11:39:43 stone kernel: md127: detected capacity change from 0 to 1000068874240
Jul 30 11:39:43 stone kernel:  md127: unknown partition table
Jul 30 11:39:43 stone systemd[1]: Starting MD array monitor...
Jul 30 11:39:43 stone systemd[1]: About to execute: /usr/lib/systemd/scripts/mdadm_env.sh
Jul 30 11:39:43 stone systemd[1]: Forked /usr/lib/systemd/scripts/mdadm_env.sh as 457
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed failed -> start-pre
Jul 30 11:39:43 stone systemd[457]: Executing: /usr/lib/systemd/scripts/mdadm_env.sh
Jul 30 11:39:43 stone systemd[457]: Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh: No such file or directory
Jul 30 11:39:43 stone systemd[1]: Received SIGCHLD from PID 457 ((m_env.sh)).
Jul 30 11:39:43 stone systemd[1]: Child 457 ((m_env.sh)) died (code=exited, status=203/EXEC)
Jul 30 11:39:43 stone systemd[1]: Child 457 belongs to mdmonitor.service
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: control process exited, code=exited status=203
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service got final SIGCHLD for state start-pre
Jul 30 11:39:43 stone systemd[1]: About to execute: /sbin/mdadm --monitor $MDADM_MONITOR_ARGS
Jul 30 11:39:43 stone systemd[1]: Forked /sbin/mdadm as 460
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed start-pre -> running
Jul 30 11:39:43 stone systemd[1]: Job mdmonitor.service/start finished, result=done
Jul 30 11:39:43 stone systemd[1]: Started MD array monitor.
Jul 30 11:39:43 stone kernel: md: md127 still in use.
Jul 30 11:39:43 stone kernel: md/raid1:md127: Disk failure on sdb1, disabling device.
                              md/raid1:md127: Operation continuing on 1 devices.
Jul 30 11:39:43 stone mdadm[460]: mdadm: No mail address or alert command - not monitoring.
Jul 30 11:39:43 stone systemd[460]: Executing: /sbin/mdadm --monitor --scan
Jul 30 11:39:43 stone systemd[1]: Received SIGCHLD from PID 460 (mdadm).
Jul 30 11:39:43 stone systemd[1]: Child 460 (mdadm) died (code=exited, status=1/FAILURE)
Jul 30 11:39:43 stone systemd[1]: Child 460 belongs to mdmonitor.service
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: main process exited, code=exited, status=1/FAILURE
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service changed running -> failed
Jul 30 11:39:43 stone systemd[1]: Unit mdmonitor.service entered failed state.
Jul 30 11:39:43 stone systemd[1]: mdmonitor.service: cgroup is empty
Jul 30 11:39:43 stone kernel: RAID1 conf printout:
Jul 30 11:39:43 stone kernel:  --- wd:1 rd:2
Jul 30 11:39:43 stone kernel:  disk 0, wo:1, o:0, dev:sdb1
Jul 30 11:39:43 stone kernel:  disk 1, wo:0, o:1, dev:sdc1
Jul 30 11:39:43 stone systemd[1]: Got disconnect on private connection.
Jul 30 11:39:43 stone kernel: RAID1 conf printout:
Jul 30 11:39:43 stone kernel:  --- wd:1 rd:2
Jul 30 11:39:43 stone kernel:  disk 1, wo:0, o:1, dev:sdc1
Jul 30 11:39:43 stone kernel: md: unbind<sdb1>
Jul 30 11:39:43 stone kernel: md: export_rdev(sdb1)

私の考えでは、これがmdmonitorRAIDを作成するのに重要かどうか疑われます。

CLIで実行すると、両方のRAIDが完全に組み立てられ、問題は発生しませんでした。

SMARTデータによると、ドライブは正常です。

実際、UUIDは同じではありません。単一のRAIDに基づいて例を作成しました。

この不一致を引き起こす私はここで何が間違っていますか？

ベストアンサー1

TL;博士

問題が何であるかを見つけました！sleep一部のパーティション操作間に少し時間がかかります。明らかに、並行性問題を偶然発見しました。

詳細はこちら：

プロセスが完了しても、カーネルがプロセスで自分の役割を完了したという意味ではないようです（カーネルが特定のプロセスの後に作業を実行する必要がある場合）。私の場合、パーティショニングは問題でした。mdadm --createあまりにも早く起動し、カーネルがまだいくつかのパーティション変更で更新されていないようです。はい、その間に何かがありますが、partprobe変更を認識していないようです。

私は偶然見つかるまでシェルスクリプト、cli phpスクリプト、Webスクリプトを使ってデバッグを始めました。

[root@stone /] parted -s /dev/sdb mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] parted -s /dev/sdc mklabel gpt unit GB mkpart primary 0 100%

[root@stone /] partprobe

[root@stone /] lsblk
sda      8:0    0  55.9G  0 disk
├─sda1   8:1    0     1M  0 part
├─sda2   8:2    0   500M  0 part /boot/efi
├─sda3   8:3    0   500M  0 part [SWAP]
└─sda4   8:4    0  54.9G  0 part /
sdb      8:16   0 931.5G  0 disk
└─sdb1   8:17   0 931.5G  0 part
sdc      8:32   0 931.5G  0 disk

命令の実行時に間隔がないため、CPUはできるだけ早く命令を処理できます。/dev/sdcパーティションテーブルがまだ更新されていないことがわかりました。

明らかに、次のコマンドはパーティションテーブルを変更せずに起動し、奇妙な動作を引き起こしましたpartprobe。mdadm --create

私の観察と仮定が完全に間違っている可能性がありますが、少なくともこれが状況を自分自身に論理的に説明する方法です。

はい、修正はsleep通貨間に以下を追加することです。

[root@stone /] parted -s /dev/sdb mklabel gpt unit GB mkpart primary 0 100%
[root@stone /] parted -s /dev/sdc mklabel gpt unit GB mkpart primary 0 100%

[root@stone /] sleep 1

[root@stone /] partprobe

[root@stone /] sleep 1

[root@stone /] lsblk
sda      8:0    0  55.9G  0 disk
├─sda1   8:1    0     1M  0 part
├─sda2   8:2    0   500M  0 part /boot/efi
├─sda3   8:3    0   500M  0 part [SWAP]
└─sda4   8:4    0  54.9G  0 part /
sdb      8:16   0 931.5G  0 disk
└─sdb1   8:17   0 931.5G  0 part
sdc      8:32   0 931.5G  0 disk

これで問題が解決しました。

ただし、最終的にRAID0の場合はシンボリックリンクは作成されませんが、RAID1の場合は生成される論理的な説明はまだ見つかりません。シンボリックリンクの生成を防ぐために準備をプッシュする方法を理解できません...

おすすめ記事