labelclearコマンドで当該デバイスからZFSラベル情報を消した方が良さそうだ。再利用デバイスで新しいプールを作ろうとすると、殆どの場合は以下のようなエラーが出て作ることができない。'zroot'「有効なプールzrootの一部かもよ」とZFS先生は仰ってるものの、zrootは間違いなくdestroy済みで、僕は確信を以てda0p3でztankを作りたいのだよ。destroyしたんだからラベル情報も一緒に消しとけよ!と思わなくもないが、ZFSではdestroyの取り消しをサポートしてたりする関係で、こういう仕様なのだろう。importの-Dオプションを調べておくんなまし。ところがである、条件は不明だが、このお節介が働かず以前のラベル情報を残したまま新プールが作れちゃうことがある。新しいプールと昔のプールが管理情報の上では存在する事になり、見るからにヤバげな状態となる。その時の再現ログが↓これ。errorsログ上からは、別々のストレージで構成される2つのプール、newtankとoldtankがあるようにしか見えない。実際のところ、oldtankはnewtank以前にda0p3で使っていたもので、既にdestroy済みのプールなのである。newtankとして実際にデータが書き込まれ、意味消失してるハズの削除済みプールoldtankが認識されているのだ...!こうなると最早手遅れ。oldtankを再度destroyしようにも「そんなプールは存在しない」と言われるし、ならばとデバイス1234567890123456789をどうにかする方向で頑張ってもどうにもならず...。言って、この段階でlabelclearは絶対にしてはいけない。́ཀ`」∠):_(実体験)。いうわけで、ZFSプールを作る時は忘れずにlabelclearで以前の情報を消すようにしたい。追記)タイミングよく本症状が発生したのでスクショをうp。root~で失敗して起動しなくなる今にして思えば、この時点で古いプールが認識されて旧zrootの方をマウントしようとしてたのかも...?kernel.oldの方から起動してfreebsd-updateで11.0の最新にしようとする見事に失敗して起動しなくなる。zfsも失敗する状態。確かにlabelclearしたハズなんだけどなぁ...。変なzpool.cacheでも食ってんのかなぁ...?わからん。追記)あ、ありのまま起こったことを(ry。症状が出たHDDの各パーティションを再度labelclearしてddでゼロフィルまでしたにもかかわらず、古い方のzrootが認識されやがったぜ......。da0してようやく認識されなくなった。(が、当然GPTは壊れる。セカンダリテーブルは生きてるからパーティションの認識と復旧は可能だが...。)GPTの領域にZFSラベルが書き込まれそうな使い方─つまりディスク全体をzpoolにするような使い方はした記憶がないんだが、どうしてこうなった......?結論としては、zpoolを作る時は対象デバイスの/dev/daXと/dev/daXpYを全てlabelclearするのが安全、可能なら全体をゼロフィルするということで。Tags:FreeBSDPCZFSCommentsNameE-MailWebsite人間の証明として、ボックス内の全ての文字を入力してください。Decomoソースの表示以前のリビジョンメディアマネージャー文書の先頭へ。