Show Table of Contents
マルチパスで、別のプログラムによって作成された
起動時に回復可能なエラーが発生した場合に、
Systemd が
マルチパスは、ブロックデバイスに属さないパスに対して、パスが
マルチパスデバイスの
マルチパスが、
dmraid のアンインストール後に、
第34章 ストレージ
/dev/disk/by-path/ が複数の NPIV パスに対応
以前のリリースでは、仮想ホストバスアダプター (HBA) が単一の物理 HBA 上に作成された場合には、
/dev/disk/by-path/ ディレクトリーで作成されるデバイスへのリンクは、1 パスあたり 1 リンクではなく、1 つのみでした。そのため、ファイバーチャネルの N_Port ID Virtualization (NPIV) を使用して仮想 HBA で virsh プールを作成すると、正常に機能しませんでした。今回の更新により、/dev/disk/by-path/ 内にシンボリックリンクが正しく作成されるようになりました、物理ファイバーチャネルの N_Port を通して接続される論理ユニット番号 (LUN) 用に udev によって作成される /dev/disk/by-path/ 内のシンボリックリンクは変更されなくなりました (BZ#1266934)。
シンプロビジョニングを使用する場合に、シンプールが最大容量に達しても、バッファーされた書き込みは失われない
以前のリリースでは、サイズ変更の操作を実行すると、自動化されている場合でも、サイズ変更の実行前に、未処理の I/O をストレージデバイスにフラッシュしようと試みていました。シンプールには容量がなかったため、最初に I/O 操作でエラーが発生してからでないと、サイズ拡張を正常に行うことはできませんでした。その結果、シンプールが最大容量に達している場合には、この操作と同時に容量が拡張されても、一部の書き込みデータが損失されてしまう可能性がありました。今回の更新では、このような状況でも、バッファーされた書き込みはシンプールから失われなくなりました (BZ#1274676)。
IBM Power Systems のリトルエンディアン版で RAID 移行が正しく機能
以前のリリースでは、IBM Power Systems の Little Endian 版でストライプのサイズを指定せずに
raid-migrate コマンドを実行すると、iprconfig ユーティリティーが RAID の現在のストライプサイズにフォールバックして、正しいエンディアンネス変換を実行せずにアダプターからロードしていたため、エラーが発生していました。今回の更新でその原因となっていたソースコードが変更され、このバグは修正されたので、RAID の移行は IBM Power Systems の Little Endian 版でも正常に機能するようになりました (BZ#1297921)。
multipathd デーモンが、使用できない暗黙的 ALUA のゴーストパスを再開しない
以前のリリースでは、
multipathd デーモンにより、使用することのできない、GHOST 状態の暗黙的 ALUA デバイスが自動的に再開されていました。そのようなデバイスしか存在しない場合には、I/O 操作が失敗するのではなく、マルチパスは使用できないデバイスに対して継続的に再試行していました。今回の修正により、multipathd は使用不可能な暗黙的 ALUA のゴーストパスを再開しなくなりました。その結果、マルチパスは、使用できない暗黙的 ALUA パスしかない場合に、I/O 操作を継続的に再試行しなくなりました (BZ#1291406)。
マルチパスがマルチパスデバイス内に 0 サイズのスタンバイパスを追加
一部のアレイでは、スタンバイポート上のサイズがレポートされないため、デバイスのサイズが 0 となります。以前のリリースでは、マルチパスは 0 サイズのデバイスをマルチパスデバイスに追加することを許可していませんでした。このため、マルチパスは 0 サイズのスタンバイパスをマルチパスデバイスに追加しませんでした。今回の更新により、マルチパスはデバイスへの 0 サイズのパスの追加を許可するようになりました (BZ#1356651)。
マルチパスで、別のプログラムによって作成された dm テーブルタイプが multipath のデバイスが変更されない
以前のリリースでは、マルチパスツールは、テーブルタイプが multipath の
dm デバイスをすべて管理する役割を果すことを前提としていました。今回の更新では、マルチパスツールは、dm UUID が mpath- (マルチパスによって作成される全デバイスに使用される UUID プレフィックス) で始まるデバイスのみで機能するようになりました。その結果、マルチパスは、他のプログラムによって作成された dm テーブルタイプが multipath のデバイスを変更しないようになりました (BZ#1241528)。
multipathd デーモンが、マルチパスデバイスの新規作成時に使用可能なパスがない場合にそのデバイスにパスを追加することを許可
以前のリリースでは、
multipathd が新規マルチパスデバイスを作成する際に、使用可能なパスがないマルチパスデバイスが作成された場合でも、そのデバイスの udev 変更イベントが確認されるまでは、パスを追加できませんでした。使用可能なパスなしにマルチパスデバイスが作成された場合には、udev デバイスマネージャーは、そのデバイス上の情報の取得を試みてハングしていまい、タイムアウトになるまではアクティブなパスを追加できませんでした。今回の修正により、multipathd はマルチパスデバイスの新規作成時にそのデバイスで使用可能なパスがない場合に、使用可能なパスを追加できるようになりました。これにより、使用可能なパスがなかった新規デバイスに使用可能なパスが直ちに追加され、udev はハングしなくなりました (BZ#1350931、BZ#1351430)。
起動時に回復可能なエラーが発生した場合に、multipathd デーモンが終了しない
以前のリリースでは、起動中に回復可能なエラーが発生すると、
multipathd はリカバリーを実行する代わりに終了していました。今回の修正により、multipathd は、回復可能なエラーが発生した場合でも稼働を継続し、終了しないようになりました (BZ#1368501)。
multipathd デーモンが、削除に失敗した場合に ok ではなく fail で応答する
以前のリリースでは、
multipathd デーモンは、パスまたはマップの削除が失敗しても、エラーのステータスを維持しなかったため、削除に失敗した場合に ok で応答していました。今回の修正により、multipathd は、削除に失敗した場合に fail で応答するようになりました (BZ#1272620)。
デバイスが追加された後に削除され uid_attribute が変わっても、Multipath はクラッシュしない
以前のリリースでは、マルチパスデバイスに追加された後に、パスの WWID が変わると、
multipathd デーモンは新規デバイスを作成していました。これにより、パスは両方のデバイスに入ってしまうため、マルチパスデバイスの作成後にユーザーが uid_attribute を変更してからデバイスを削除すると、multipathd は解放されたメモリーへのアクセスを試みてクラッシュしてしまうことがありました。今回の修正により、multipathd はパスがマルチパスデバイスで使用中の場合には WWID を変更しなくなりました。その結果、multipathd はこのシナリオではクラッシュしなくなりました (BZ#1323429)。
マルチパスでデバイスの名前変更中にエラーが発生しない
以前のリリースでは、マルチパスは、デバイスの名前を変更する関数で、初期化されていない変数を使用していました。そのため、変数は無効な値に設定されて、マルチパスはデバイスの名前変更中にエラーが発生することがありました。今回の修正により、マルチパスは、デバイスの名前変更時にこの変数を初期化するようになりました (BZ#1363830)。
Systemd が multipath.pid ファイルが読み取り不可能と報告しない
以前のリリースでは、systemd は
multipathd コマンドが返された後に multipathd.pid ファイルを読み取りできないと報告していました。これは、デーモンをフォークした直後に multipathd コマンドが返されて、デーモンは設定が完了するまで pid ファイルに書き込みを行わないことが原因でした。今回の修正により、multipathd コマンドは、multipathd デーモンが pid ファイルへの書き込みを完了するまで待つか、処理が返されるまで 3 秒経過するのを待つようになりました。またデーモンは、起動の初期段階で pid ファイルに書き込みを行うようになりました。その結果、systemd は multipath.pid ファイルが読み取り可能でないことを報告しなくなりました (BZ#1253913)。
マルチパスは、ブロックデバイスに属さないパスに対して、パスが not a valid argument (有効な引数ではない) というメッセージを表示
以前のリリースでは、有効なブロックデバイス以外へのパスを使用すると、マルチパスは
requires a path to check という、あまり役に立たないメッセージを表示していました。これは、マルチパスが、ブロックデバイスパスと major:minor 番号以外は、マルチパスのエイリアスと判断していたためでした。今回の修正により、マルチパスは、ブロックデバイス以外への完全修飾パスをマルチパスのエイリアスとして扱わなくなりました。その結果、マルチパスはブロックデバイスに属さないパスに対してパスが not a valid argument というメッセージを表示するようになりました (BZ#1319853)。
マルチパスデバイスの /dev/mapper エントリーがすべて udev によって作成されたシンボリックリンクになる
以前のリリースでは、
/dev/mapper エントリーはシンボリックリンク (symlink) の場合と、ブロックデバイスの場合がありました。これは、マルチパスが、udev による /dev/mapper/ symlink の作成を適切に待たなかったことが原因でした。今回の修正により、マルチパスは各トランザクションの後に、 udev を待つようになったため、マルチパスデバイスの /dev/mapper エントリーはすべて udev によって作成された symlink となりました (BZ#1255885)。
マルチパスが新規デバイス上にマルチパスデバイスを作成するとすぐに、それらの新規デバイスはマルチパスによって要求される
以前のリリースでは、マルチパスによって初めてデバイスが確認された時には、
udev ルール内では、マルチパスによって要求されませんでした。これは、マルチパスが、uevent を処理する際に、WWID が /etc/multipath/wwids ファイルになければ、udev のデバイスは要求しないのが理由です。今回の修正により、マルチパスが新規デバイスの WWIDを wwids ファイルに追加すると、そのデバイス上で変更イベントが発行されて、マルチパスは udev ルール内でデバイスを要求することができるようになりました。マルチパスが新規デバイス上にマルチパスデバイスを作成するとすぐに、マルチパスがそのデバイスを要求するようになりました (BZ#1299600)。
一部のデバイスでエラーが発生しても、マルチパスによる他のデバイスの作成が妨げられない
以前のリリースでは、関係のないデバイスのエラーによって、
multipath コマンドが作業デバイスの設定に失敗する場合がありました。これは、作成しようとしているデバイスの情報の取得に失敗した場合には、操作が早く終了してしまうことが原因でした。今回の修正により、マルチパスは、いずれかのデバイスの情報の取得に失敗しても早く終了しなくなり、デバイス上でエラーが発生しても、マルチパスによる他のデバイスの作成は妨げられなくなりました (BZ#1313324)。
マルチパスが、 uevent メッセージを見落とさなくなり、適切なデバイスをすべて追加する
以前のリリースでは、マルチパスデバイスは、すべてのパスデバイスを正しく追加しませんでした。
uevent ソケットのサイズ変更のサポートを実装してコンパイルするための libudev 関数の有無を正しく確認していなかったことが原因でした。そのため、マルチパスは、uevent ソケットのサイズ変更をせず、オーバーフローしてしまう可能性があったため、必要なイベントを見落としていました。今回の修正により、マルチパスは適切な libudev 関数の有無を確認し、uevent ソケットのサイズ変更に対するサポートを実装してコンパイルするようになった結果、マルチパスは uevent メッセージを見落とすことはなくなり、適切なデバイスをすべて追加するようになりました (BZ#1296979)。
kpartx ツールが、デバイスが作成される前に値を返さない
以前のリリースでは、
kpartx ツールはデフォルトで、デバイスの作成が完了するのを待たずに値を返していました。これは、kpartx が値を返した直後にデバイスが終了すると予想していたユーザーにとって、混乱の原因となっていました。今回の更新により、kpartx はデフォルトでデバイスの作成が完了するのを待ってから値を返すようになりました (BZ#1299648)。
1 つのデバイスをサイズ変更するコールが複数回実行された場合に、各コールがデバイスのサイズ変更を試みて、結果を正しく報告する
以前のリリースでは、
multipathd がデバイスのサイズ変更に失敗した場合でも、デバイスのサイズが新たに変更されたという認識が変わりませんでした。その後にデバイスのサイズ変更のコールを実行しても、multipathd は実行すべき操作は残っていないと判断するため、操作が成功したというメッセージが返され、デバイスのサイズ変更は行われませんでした。今回の修正により、サイズ変更が失敗した場合には、multipathd がデバイスのサイズを元のサイズにリセットするようになったため、サイズ変更のコールを複数回実行しても、各コールでサイズ変更の操作が試みられ、その結果が正しく報告されるようになりました (BZ#1333492)。
マルチパスは、サイズが 2 TB を超える DOS パーティションで、4 k のブロックデバイス向けのパーティションデバイスを正しく作成する
以前のリリースでは、2 TB を超える DOS パーティションでは、
kpartx ツールにより、サイズが 4 k のブロックデバイス向けに誤ったサイズのパーティションが作成されていました。これは、kpartx がセクター数を保管して、乗数がネイティブのセクターサイズを 32 ビットの符号なし整数で 512 バイトのセクターに変換する必要があったことが理由です。このために 2 つの数字を掛けあわせた値が 2^32 を超える場合には、ロールオーバーされていました。今回の修正により、マルチパスは、セクターサイズの乗数の変数に 64 ビットの符号なし整数を使用するようになったため、これらが掛け合わされても、結果はロールオーバーされなくなりました。その結果、マルチパスはパーティションを正しく作成するようになりました (BZ#1311463)。
マルチパスは、使用中のパーティションを削除せずに、パスが再度追加された場合には復元する
以前のリリースでは、デバイスへの全パスが失われた場合には、マルチパスが使用していないパーティションをすべて削除してしまい、それらを復元することはありませんでした。この問題は、マルチパスがデバイスの削除を試みると、使用中のパーティションがある場合でも削除してしまい、一旦削除されるとそれらのパーティションを復元することがなかったために発生していました。今回の修正により、マルチパスは削除を試みる前にパーティションが使用中かどうかを確認し、削除が失敗した場合には、パスが再度追加された際にそれらのパーティションを復元するようになりました (BZ#1292599)
kpartx ツールは、新規デバイスの名前が既存のデバイスの名前と一致している場合でも、既存のパーティションを上書きしない
以前のリリースでは、新しく作成しようとしているデバイスの名前が既存のデバイス名と一致している場合には、
kpartx は警告なしに既存のパーティションデバイスを新しい名前で上書きしていました。そのため、名前の競合が発生した場合には、kpartx デバイスのポイント先が突然変更されてしまいました。今回の修正により、kpartx は UUID を確認して、別のデバイス全体に属するパーティションデバイスを上書きしないようになりました。名前の競合が発生した場合には、既存のデバイスのポイント先を変更してしまう代わりに、kpartx でエラーメッセージが表示されて操作が失敗します (BZ#1283750)。
mpathconf --allow コマンドは、ノードがブートするために許可されている正しいデバイスを指定する設定ファイルを作成する
以前のリリースでは、特定の環境で
mpathconf --allow コマンドによりノードがブートすることができない設定ファイルが作成されていました。この問題は、mpathconf --allow によって設定ファイルの blacklist_exceptions セクションから既存のエントリーが削除されてしまったために、一部の許可されているデバイスがブラックリストされてしまう場合があるために発生していました。またこのコマンドにより、blacklist_exceptions セクションに重複した WWID のエントリーが出力されていました。今回の修正により、mpathconf --allow は既存の blacklist_exceptions エントリーを削除しなくなり、また WWID エントリーは 1 回しか出力されないようになりました。このコマンドは常に、ノードをブートするために許可されている正しいデバイスを指定して設定ファイルを作成するようになりました (BZ#1288660)。
マルチパスデバイスが LVM 物理ボリュームとして正しく識別される
以前のリリースでは、LVMがマルチパス PV の認識に失敗することがありました。これは、
multipathd が、作成の uevent を受信するのと同時に、デバイスをリロードする場合があったためです。LVM の udev ルールでは、現在サスペンド状態のデバイスの処理は許可されませんが、この処理はリロード中に行われます。今回の修正により、multipathd は作成の uevent を受信するまでデバイスのリロードを遅らせるようになりました (BZ#1304687)。
multipathd デーモンは、パスが実際には down の場合に up と出力しない
以前のリリースでは、
multipathd デーモンは、パスが実際には down の状態の場合に up と出力する場合がありました。multipathd がパスチェッカーを呼び出す前にパスが down であることを検出した場合でも、最後のパスチェッカーのメッセージを消去せず、それを出力してしまっていました。今回の修正により、multipathd は、チェッカーが実行される前にパスが down 状態と確認された場合には、パスチェッカーのメッセージを消去するようになりました (BZ#1280524)。
multipathd デバイスの作成は、udev がパーティションデバイスを同時に処理しても操作が失敗しない
以前のリリースでは、
multipathd は、udev がパスデバイスに対するロックを取得している場合には、マルチパスデバイスを作成できませんでした。この問題は、multipathd がマルチパスデバイスの作成中にパスデバイスに対する排他的ロックを取得し、udev がパーティションデバイスの処理中にそのパスデバイスに対する共有ロックを取得するために発生していました。今回の修正により、multipathd は共有ロックも取得するようになったので、udev と同時に実行できるようになりました (BZ#1347769)。
systemd は依存関係が不足しているという警告のメッセージを出力しない
以前のリリースでは、
systemd により、依存関係の不足についての警告のメッセージが出力されていました。multipathd systemd サービスユニットファイルには、 initramfs では利用できない別のユニットファイルが必要でした。今回の修正により、multipathd ユニットファイルは、blk-availability ユニットファイルがなくても動作できるように、Requires の代わりに Wants を使用するようになりました (BZ#1269293)。
kpartx によって生成されるデバイスには、実際のパーティション番号と同じパーティション番号が付けられる
以前のリリースでは、
kpartx によって生成されるデバイスのパーティション番号が実際のパーティション番号と一致しませんでした。これは、kpartx がセクターのない sun のパーティションを数に入れていなかったのが原因でした。今回の修正により、kpartx は、パーティション番号を決定する際に、セクターのない sun のパーティションを数に入れるようになり、kpartx によって生成されたデバイスには、実際のパーティション番号と同じパーティション番号が付けられるようになりました (BZ#1241774)。
MTX は大型のテープストレージアレイでも操作が失敗しない
以前のリリースでは、大型のテープストレージドライブアレイを使用して構成されているシステムでは、MTX ツールでエラーが発生して操作が失敗していました。そのため、そのテープストレージを管理することができませんでした。今回の更新により、大型のテープストレージアレイのサポートが改善され、MTX は大型のテープストレージを想定どおりに管理できるようになりました (BZ#1298647)。
dmraid と他の device-mapper サブシステム間で干渉が発生しない
以前のリリースでは、dmraid パッケージが間違ったテストオプションでコンパイルされていたため、
dmraid ツールは意図せずに、LVM などの 他の device-mapper サブシステムを含む全デバイスをスキャンしてしまい、それらの別のサブシステムに干渉が発生し、ブート時にさまざまなエラーが発生する場合がありました。今回の更新により、dmraid でテストモードが無効となり、ブート時に全デバイスがスキャンされないようになりました。その結果、dmraid とその他の device-mapper サブシステム間の干渉は発生しなくなりました (BZ#1348289)。
dmraid のアンインストール後に、systemd が dmraid-activation.service で不足しているユニットについての警告を表示しない
今回の更新の以前は、dmraid パッケージをアンインストールした後でも、
/etc/systemd/system/sysinit.target.wants/dmraid-activation.service のシンボリックリンクがシステムに残っていたため、systemd サービスによって dmraid-activation.service で不足しているユニットについての警告が表示されていました。今回の更新により、このシンボリックリンクは dmraid のアンインストール時に削除されるようになりました (BZ#1315644)。
mdadm が再形成中に IMSM RAID アレイの停止に失敗しない
以前のリリースでは、バグが原因で、再形成中に Intel Matrix Storage Manager (IMSM) RAID アレイの停止を試みるとエラーが発生していました。このバグを修正するために問題の原因となっていたソースコードが変更され、
mdadm ユーティリティーは、このような状況でアレイを適切に停止するようになりました (BZ#1312837)。
mdadm を使用して、I/O 操作の実行中に機能低下したアレイにホットスペアを割り当ててもエラーが発生しない
以前のリリースでは、MD アレイ上で I/O 操作の実行中に機能低下したアレイにホットスペアを割り当てると操作が失敗し、
mdadm ユーティリティーが以下のようなエラーメッセージを返していました。
mdadm: /dev/md1 has failed so using --add cannot work and might destroy mdadm: data on /dev/sdd1. You should stop the array and re-assemble it
このバグを修正するためのパッチが適用され、このような状況で機能低下したアレイにホットスペアを追加しても、操作が想定どおりに完了するようになりました (BZ#1300579)。
mdadm によって作成された機能低下した RAID1 アレイがリブート後に非アクティブ状態で表示されない
以前のリリースでは、
mdadm ユーティリティーを使用して作成された、機能低下した RAID1 アレイが、システムの再起動後に非アクティブな RAID0 アレイとして表示される場合がありました。今回の更新により、このようなアレイはシステムの再起動後に正しく起動されるようになりました (BZ#1290494)。
RAID0 アレイに対してビットマップを含む RAID1 アレイの再形成を試みても、RAID1 アレイは破損しない
mdadm ツールを使用してビットマップを含む RAID1 アレイを RAID0 アレイに対して再形成する操作はサポートされていません。以前のリリースでは、ビットマップを含む RAID1 アレイを RAID0 アレイに対して再形成を試みると操作は拒否されましたが、RAID1 アレイが破損していました。今回の更新により、再形成の操作は拒否されますが、RAID1 アレイは想定どおりに機能し続けるようになりました. (BZ#1174622)。
mdadm で再形成の操作を実行している IMSM RAID アレイで競合状態が発生しない
以前のリリースでは、
mdadm の再形成操作を実行する Intel Matrix Storage Manager (IMSM) RAID アレイでは、競合状態が発生した場合には、最初の操作が完了する前に、同じアレイで 2 番目の再形成の操作を起動することが可能だったため、最初の再形成の操作が完了しない場合がありました。今回の更新により、このような競合状態は発生しなくなり、1 回目の再形成操作が完了するまで 2 回目の操作は開始できないようになりました (BZ#1347762)。
mdadm が 15 文字を超えるデバイス名を使用するアレイをアセンブルできる
以前のリリースでは、15 文字以上のデバイス名が付いたデバイスを含むアレイのアセンブルを試みると、セグメンテーション違反が発生して、
mdadm ユーティリティーは予期せずに終了することがありました。今回の更新によりアレイが 15 文字を超えるデバイス名を使用している場合でも、mdadm はアレイを正しくアセンブルするようになりました (BZ#1347749)。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.