3つのネストされたRAIDZ2 vdevを持つ大規模なZFSディスクプールがあります。
同僚のために故障したディスクを交換するプロセスを文書化しているので、ホストからディスクを削除してディスクの故障をシミュレートしています。
もちろん、ディスクが属するvdevがダウングレードされているため、ディスクは利用できません。
これでディスクをオフラインにします。
zpool offline diskpool sdo
高速「zpoolステータス」は、ディスクがオフラインであることを示します...これまでは良好です。
ディスクを交換し、SATAコントローラで新しいディスクが検出されたことを確認しました。その後、Linuxはscsiバスを再スキャンしてディスクを検出しようとしました。これが私の最初の質問が起こるところです。
私が知っている限り、次のコマンドは再検索する正しいホストバスを見つけるために使用されます。
grep mpt /sys/class/scsi_host/host?/proc_name
しかし、私のCentos 7.2システムでは、このコマンドは出力を生成しません。エラーはなく、空の出力を提供し、次のコマンドを待ちます。
私は多くのSATAデバイスを接続できるいくつかの特別なカードを使います。私は通常バスを再検索します
echo "- - -" > /sys/class/scsi_host/hostX/scan
ここで、hostXは正しいホストバスですが、ホストバスが見つからないため、この手順を完了できません。
この情報を取得する他の方法はありますか？それともCentos 7.2などでコマンドが変更されましたか？
また、テストを続行するためにコンピュータを再起動することにしました。再起動後、ZFSプールは接続されません。 「zpool import diskpool」を使用して手動でインポートする必要がありました。これはうまくいきますが、奇妙なことは、インポート後に「zpool status」を実行すると、以前のようにデバイスIDが表示されなくなることです。
raidz2-2 ONLINE 0 0 0
/dev/sdd ONLINE 0 0 0
/dev/sde ONLINE 0 0 0
/dev/sdf ONLINE 0 0 0
/dev/sdg ONLINE 0 0 0
代わりにドライブのシリアル番号があるようです...
raidz2-2 ONLINE 0 0 0
ata-ST8000AS0002-1NA17Z_Z840DG66 ONLINE 0 0 0
ata-ST8000AS0002-1NA17Z_Z840DVE0 ONLINE 0 0 0
ata-ST8000AS0002-1NA17Z_Z840CQFB ONLINE 0 0 0
ata-ST8000AS0002-1NA17Z_Z840DP2V ONLINE 0 0 0
これにより将来の問題が発生する可能性があり、他のディスクに障害が発生した場合は、交換する正しいディスクを決定するのが困難になります。
デバイスIDが再び表示されるように切り替える方法はありますか？
よろしくお願いします！
ベストアンサー1
ファイルシステムの名前でディスクを検出する代わりに、ZFSはディスクにUUID（または少なくとも同様のもの - 実際にUUIDであるかどうか100％不確定）を記録してディスクを検出します。実行するとzpool importディスクが列挙され、ZFSはすべてのプールを再構築し、出力にデバイス名を使用します（実際にはディレクトリIMEを含まず、通常は次のようにsda表示されます/dev/sda）zpool status。したがって、ドライブを移動した場合（またはコアドライブを移動すると（これは最新のハードウェアの最新のカーネルで発生する可能性があります）、zpoolはまだ以前と同じ順序でディスクを検出します。カーネルが出力に表示されなくなった場合でも、最初に出力に表示されます。この出力にこれを列挙します。
ここで何が起こるのかは、おそらく元のバージョンがzpool import機能せず、カーネルが起動を完了し、多くのタスクを実行してから手動を実行するudevと、すべてのディスクのデフォルトの列挙zpool import結果が最初のシリアル番号に基づいていることです。場所ではありませんsdX。次にコンピュータを再起動すると、使用された名前がそのスキームにsdX戻る可能性が高くなります。
幸いなことに、ある命名体系から別の命名体系に名前を付けることは非常に簡単です。
wouter@gangtai:/dev/disk/by-id$ ls -l
total 0
lrwxrwxrwx. 1 root root 9 Mar 31 18:15 ata-SAMSUNG_MZ7TE256HMHP-00004_S1RKNSAFC04685 -> ../../sda
lrwxrwxrwx. 1 root root 10 Mar 31 18:15 ata-SAMSUNG_MZ7TE256HMHP-00004_S1RKNSAFC04685-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 9 Mar 31 18:15 wwn-0x50025388a089e89c -> ../../sda
lrwxrwxrwx. 1 root root 10 Mar 31 18:15 wwn-0x50025388a089e89c-part1 -> ../../sda1
by-idさまざまな命名システム（、by-uuidおよび）がありby-path、すべて以下で確認できます/dev/disk。
すべてを言いましたが、名前を見れば、どのディスクがどのディスクであるかを理解する方が簡単であるというあなたの声明に同意しませんsdX。最新のカーネルは、特定のデバイスに静的デバイス名を割り当てなくなりました。これは、最新のディストリビューションがUUIDベースのfstabファイルの代わりにsdXUUIDベースのファイルを使用する理由です。シリアル番号は実際に遠くどのディスクが損傷しているかを確認するより安定した方法は、それが記録された方法です。物理ディスク上は名前とは異なり、起動sdXごとに異なる場合があります（実際には16台のハードドライブがあるZFSシステムでこの問題が発生しました）。他のアプローチ（by-uuid特にby-idエンタープライズby-pathクラスのマルチディスクエンクロージャの場合）はたくさんそれよりも信頼できます。