☰

サーバーに新しいディスクを追加した後、zpool が使用できなくなります (マウント ポイントが変更されました)

tag-icon • tag-icon linux hard-drive raid mount zfs
サーバーに新しいディスクを追加した後、zpool が使用できなくなります (マウント ポイントが変更されました)

私は 2 つの zpool を備えた Proxmox を実行しているホームサーバーを持っています。既存のプールを小さな HDD で新しいものに置き換えたいのですが、2 つの新しい SATA HDD のうちの 1 つをプラグインすると、zpool が動作しません。ログには重要なディスクが見つからないと表示されています。新しいディスクをディスパッチすると、すべて正常に動作します。

私は私の新しいディスクは にマウントされていますsda。しかし、新しいディスクが接続されていないときに、既存の zpool 内の古いディスクの 1 つも にマウントされていますsda。この競合を回避するにはどうすればよいでしょうか。sda古いディスク用に zpool から が予約されており、新しいディスクには を使用する必要があることを Linux に伝える必要がありますsdg。

このような動作が発生する可能性があるということ自体に困惑しています。結果として、Linux は Windows のドライブ文字のようにマウント ポイントをドライブにバインドしないようです。マウント ポイントを使用するのは間違いで、zpool で一意の識別子 (UUID?) を使用する必要があると思います。しかし、どうすればいいのでしょうか。マウント ポイントを使用した既存の zfs プールがあります。

答え1

問題に関する背景知識

少し調べて試してみたところ、zfs はマウント ポイントを使用していることがわかりました。つまり、私の理論は正しかったのです。マウント ポイントは、Windows のドライブ文字のように静的ではありません。代わりに、Linux は起動時に検出された順序でマウント ポイントを割り当てます。ディスクを追加または削除すると、マウント ポイントが混在する可能性があります。

簡単な例:

sda -> Drive #1
sdb -> Drive #2
sdc -> Drive #3

ここで、新しいドライブ #4 を追加します。次のように挿入できます。

sda -> Drive #1
sdb -> Drive #4
sdc -> Drive #2
sde -> Drive #3

マウントポイントに依存していると、問題が発生します。システムはドライブ#2を期待していますsdbが、まったく異なるドライブ（ドライブ#4）を取得しました。Arch Wikiによると、これは通常のブート中にも発生する可能性があります。それなしHDD への変更。

私たちは何ができる？

まあ、これらのマウントポイントを使うのは良くない考えのようです。永続的なブロックデバイスの命名代わりに、udev を使用して使用できます。これは、最近の Linux ディストリビューションで使用できるはずです。永続的なブロック名は、sdaやのような中立的な名前を使用sdbしません。代わりに、ドライブに永続的にバインドされる何らかの名前を作成します。これらは、Windows のドライブ文字に相当します (はい、ドライブ文字はパーティションにバインドされ、ブロック名はドライブを識別しますが、どちらも永続的であることに注意してください)。

by-idこの問題を解決するのに最も関連しているように思われますがby-uuid、他にもあります。Arch のリンクされた wiki ページで、より詳細な説明を読むことができます。これは一般的な記事であり、他のディストリビューションにも適用できます。この問題では、生成された一意の ID の一種であることを知っておくことが重要です。メーカー、モデル、シリアル番号などの HDD 固有の情報を使用しているため、より読みやすい代替手段としてuuids使用できます。ids

ZFS

としてここで説明以前は、すべてのプールをエクスポートしてから再インポートする必要がありましたが、-dスイッチを使用しました。デバイスを検索する場所を zpool に指示します。

zpool export <poolname>
zpool import -d /dev/disk/by-id <poolname>

これを使用してzpool status検証できます: エクスポート/インポートの前に、/dev/sdaデバイスのようなマウント ポイントが表示されます。これらの手順を実行すると、ディスク ID に変更されるはずです。

通常のボリューム（オプション）

私にとってはこれでは不十分でした。私はさらにHDDを持っていますバッファISO イメージなどのため。重要なデータはなく、SSD を解放するだけです。つまり、これは古典的な ext3 ボリュームでした。まったく同じ問題がここで発生するため、サーバーの起動が妨げられます。マウント ポイントが変更されたため、新しいディスクが原因でマウントが失敗します。

私は、このドライブを削除するだけでこの問題を解決しました。とにかく、これは私のアイデアでした。新しい HDD は十分な大きさで、ディスクの数を減らすことでエネルギーを節約できるからです。これを行うには、/etc/pve/storage.cfgファイルを使用して proxmox からストレージを削除する必要があります。私の場合、関連する部分は次のようになります。

dir: buffer
path /buffer
content iso

削除した後、 を確認する必要があります/etc/fstab。このファイルは/bufferボリュームをマウントしますが、ここで根本的な原因が発生します。

/dev/sdf /buffer ext3 rw 0 0

ご覧のとおり、マウント ポイントは/dev/sdfここに存在します。私のようにディスクを拒否したくない場合は、ここで一意のマウントポイントを使用してください。たとえば、/dev/disk/by-idこれは永続的なブロック デバイス名の例です。デバイス依存データに基づいて生成されます。by-idたとえば、ハードウェアのシリアル番号を使用します。したがって、2 つの同等のディスクをデバイス化することもできます。背景情報については、最初の段落をお読みください。

私の場合、この行を削除するだけで Linux が HDD をマウントできなくなります。ボリュームがさらにある場合は、再起動後に問題が発生しないように、ボリュームごとにこれらの手順を繰り返す必要があります。

関連情報