web-dev-qa-db-ja.com

ZFSプールは欠落しているデバイスを報告しますが、欠落していません

Linuxで最新のDebian7.7x86とZFSを実行しています

コンピューターを別の部屋に移動した後。 zpoolステータスを実行すると、次のステータスになります。

  pool: solaris
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: none requested
config:

NAME                                            STATE     READ WRITE CKSUM
solaris                                         DEGRADED     0     0     0
  raidz1-0                                      DEGRADED     0     0     0
    11552884637030026506                        UNAVAIL      0     0     0  was /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1
    ata-Hitachi_HDS723020BLA642_MN1221F308D55D  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30N4JED  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30N4B2D  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30JBJ8D  ONLINE       0     0     0

使用不可と表示されているディスクは/ dev/sdb1です。少し調べてみたところ、ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1は/ dev/sdb1に微笑んでいるだけで、存在していることがわかりました。

lrwxrwxrwx 1 root root 10 Jan  3 14:49 /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1 -> ../../sdb1

スマートステータスを確認すると、次のようになります。

# smartctl -H /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-AMD64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

ディスクはそこにあります。私はそれでfdiskをすることができます、そして他のすべて。

私がそれを切り離そうとすると、次のようになります：

zpool detach solaris 11552884637030026506
cannot detach 11552884637030026506: only applicable to mirror and replacing vdevs

また、/ dev/sdb/dev/sdb1と長いby-id名を試してみました。いつも同じエラー。

私もそれを置き換えることはできません、または他の何かのようです。私はコンピュータの電源を切ったり入れたりしようとしたが、役に立たなかった。

実際にハードディスクを自分で交換しない限り、この問題の解決策は見当たりません。

アイデア？

[更新]吠えた

# blkid 
/dev/mapper/q-swap_1: UUID="9e611158-5cbe-45d7-9abb-11f3ea6c7c15" TYPE="swap" 
/dev/sda5: UUID="OeR8Fg-sj0s-H8Yb-32oy-8nKP-c7Ga-u3lOAf" TYPE="LVM2_member" 
/dev/sdb1: UUID="a515e58f-1e03-46c7-767a-e8328ac945a1" UUID_SUB="7ceeedea-aaee-77f4-d66d-4be020930684" LABEL="q.heima.net:0" TYPE="linux_raid_member" 
/dev/sdf1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="9314525646988684217" TYPE="zfs_member" 
/dev/sda1: UUID="6dfd5546-00ca-43e1-bdb7-b8deff84c108" TYPE="ext2" 
/dev/sdd1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="1776290389972032936" TYPE="zfs_member" 
/dev/sdc1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="2569788348225190974" TYPE="zfs_member" 
/dev/sde1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="10515322564962014006" TYPE="zfs_member" 
/dev/mapper/q-root: UUID="07ebd258-840d-4bc2-9540-657074874067" TYPE="ext4"

Mdadmを無効にして再起動すると、この問題が再発します。sdbがlinux_raid_memberとしてマークされている理由がわかりません。それをクリアする方法は？

debianzfszfsonlinux
1
Trausti Thor

zpool clear solarisを実行してから、zpool status -vの結果を投稿するだけです。

関連するハードウェアと使用しているコントローラーを知っておくと便利です。

編集

blkidの出力を見ると、以前のLinuxソフトウェアRAIDの残骸があります。それをクリアするには、mdadm --zero-superblock /dev/sdb1する必要があります。

2
ewwhite

インターネットとサーバーの障害とスタックオーバーフローを1日以上検索した後、何も見つかりませんでした。この質問をすると、右側の関連する質問に答えが表示されます。だから私はこの質問でこれに対する答えを見つけました：

アップグレードされたUbuntu、1つのzpool内のすべてのドライブが使用不可とマークされています

何らかの理由で、madmは開始時に実行され、md0を開始します（エラーに示されているように）md0にディスクが含まれていない場合でも、このエラーが発生します。

とてもシンプルです

mdadm --stop /dev/md0

トリックをしました、そして今私のディスクは再銀色になっています。名探偵コナン。

1
Trausti Thor

これは5年前の質問であり、当面の問題は解決されました。しかし、これは、不足しているZFSデバイス（少なくとも私が使用したキーワード）に関するWeb検索で表示される数少ない特定の検索結果の1つであり、他の人がこれを知るのに役立つ可能性があります。

デバイスが「失われる」というこの特定の問題は、Linux上のZFSの既知の問題です。 （特にLinuxの場合）問題は2つあると思います。ZOLチームは（おそらく多くの作業で）自分で修正できますが、完全にではありませんZOLの問題：

  1. デバイスを参照する完全に安定した方法を備えたOSはありませんが、この特定のユースケースでは、Linuxは、たとえばIllumos、BSD、またはSolarisよりも少し劣っています。もちろん、デバイスID、GUID、さらには新しい「WWN」標準があります。しかし、問題は、一部のストレージコントローラー（特に一部のUSB（v3および4）コントローラー、eSATAなど）、および多くの種類のコンシューマーグレードの外部エンクロージャーが常にそれらを認識できないか、さらに悪いことに、それらをOSに渡さないでください。ケーブルを外部エンクロージャーの「間違った」ポートに接続するだけで、ZFSでこの問題が発生する可能性があり、回避することはできません。

  2. 何らかの理由で、ZOLは、ディスクが実際に存在し、OSに表示されていることを認識できません。これは、ZFSが以前に知っていた以前の場所（例：/ dev、/ dev/disk/by-id、by-path）ではありません。 、by-guidなど）または1つの特定の前の場所、より要点。何かを移動する前に適切なzpoolエクスポートを行ったとしても。これは、特にZOLまたはZFSについて特に苛立たしいことです。 （Solarisでもこの問題を覚えていますが、ZILが失われるとプール全体が失われる非常に古いバージョンのZFSでした...一度すべてを失いました[バックアップがありました]。）

明らかな回避策は、ZFSでコンシューマーグレードのハードウェアを使用しないことです、特に一部のコンシューマーを使用するコンシューマーグレードの外部エンクロージャー- USB、Firewire、eSATAなどのレベルプロトコル（外部SASで問題ありません））

特に、消費者向けの外部エンクロージャーは、私に終わりのない頭痛の種を引き起こしました。わずかに「エンタープライズ」グレードのLSI SASコントローラーと5x4ベイを備えたラックマウントシャーシでこの特定の問題が発生することがありましたが、3つの外部ベイを備えたよりポータブルなソリューションに移行すると、かなり解き放たれました。ありがたいことに、私のアレイはスリーウェイミラーのストライプです。これは、ある時点で、文字通り8ドライブ（合計12個のうち）を追跡できなくなったためです。唯一の解決策は、それらを再シルバー化することでした（これは、ほとんどがGB/sで読み取られたため、少なくとも数日または数週間はかかりませんでした）。

ですから、長期的な解決策が何であるかはわかりません。 Linuxの場合、コンシューマーグレードのハードウェアのすべてのEdgeケースをカバーすることが範囲外であると感じた場合、このコードの山に取り組んでいるボランティアを非難するつもりはありません。

しかし、ZFSが各ディスクでそれ自体を管理するメタデータのより徹底的な検索を実行した場合、多くの関連する問題が修正されると思います。 （たとえば、Btrfsはこの問題にまったく悩まされていません。ウィリー・ニリーの周りを完全にランダムに移動でき、一度も文句を言うことはありません。確かに、BtrfsにはZFS（プロと短所は無限です）、そしてそれはネイティブLinuxでもあります-しかしそれは少なくとも問題が理論的には少なくとも解決できることを示していますLinuxでは、特にソフトウェア自体によって。

この問題の回避策をまとめて、allのZFSアレイに、職場でも、エンタープライズハードウェアでも実装しました。

  1. ZFSがプールを自動的にインポートしないように、外部エンクロージャーをオフにします。 （これを行わないようにZFSに指示する方法がまだないように思われるのはイライラします。キャッシュファイルの名前を変更したり、「none」に設定したりしても機能しません。アドレス指定の問題がなくても、プールを自動化することはほとんどありません。マウントしますが、むしろ自動スクリプトがそれを行います。）

  2. システムが起動して落ち着いたら、外部エンクロージャーの電源を入れます。

  3. プールを連続して数回エクスポートおよびインポートするスクリプトを実行します（正当な小さな変更でさえも表示するために、イライラする場合があります）。ここで最も重要なことは、読み取り専用モードでインポート自動再銀のキックオフを回避することです。

  4. 次に、スクリプトは、読み取り専用プールのzpool statusの出力をユーザーに表示し、先に進んで完全な読み取り/書き込みモードでインポートしてもよいかどうかをユーザーに確認します。

これを行うことで、私（または私のデータ）を数え切れないほど節約できました。通常、アドレス指定が元の場所に戻るまで、ドライブやケーブルだけを移動する必要があることを意味します。また、-dスイッチを使用してさまざまなアドレス指定方法を試す機会も提供します。それとケーブル/場所の変更のいくつかの組み合わせは、問題を数回解決しました。

私の特定のケースでは、通常、-d /dev/disk/by-pathを使用したマウントが最適な選択です。私の以前のお気に入りである-d /dev/disk/by-idは、実際には私の現在の設定ではかなり信頼できません。通常、ドライブのベイ全体が/dev/disk/by-idディレクトリから完全に欠落しているだけです。 （そしてこの場合、Linuxでさえ非難するのは難しいです。これは、前述の既存の欠点をさらに悪化させる、ただの奇抜な設定です。）

確かに、それは手動の介入なしにサーバーが自動的に起動することを信頼できないことを意味します。しかし、1）大きなバッテリーバックアップでフルタイムで実行されること、2）移動に2人と台車を必要としない消費者向けハードウェアを使用できるという利点のために、そのトレードオフを故意に行いました。 。それはOKのトレードオフです。

（編集：修正。）

0
Jim