zpool nicht verfügbar, nachdem dem Server eine neue Festplatte hinzugefügt wurde (Einhängepunkt geändert)

Question

Ich habe einen Homeserver mit Proxmox und zwei Zpools. Ich möchte einen vorhandenen Pool mit kleineren Festplatten durch einen neuen ersetzen. Aber wenn ich eine der beiden neuen SATA-Festplatten anschließe, funktionieren meine Zpools nicht. In den Protokollen steht, dass eine wichtige Festplatte fehlt. Wenn ich die neue Festplatte zusende, funktioniert alles einwandfrei.

Ich fand heraus, dass meineneuDie Festplatte ist in gemountet sda. Aber eine der alten Festplatten im vorhandenen Zpool ist auch in gemountet, sdawenn die neue nicht angeschlossen ist. Was kann ich tun, um diesen Konflikt zu vermeiden? Ich muss Linux mitteilen, dass sdadie alte Festplatte im Zpool reserviert ist und es sie sdgfür die neue verwenden soll.

Ich bin verwirrt, dass dieses Verhalten überhaupt auftreten kann. Infolgedessen scheint Linux Einhängepunkte nicht wie Laufwerksbuchstaben in Windows an Laufwerke zu binden. Ich denke, es war ein Fehler, den Einhängepunkt zu verwenden, und ich sollte in zpool eine eindeutige Kennung (UUID?) verwenden. Aber wie kann ich das machen? Ich habe vorhandene ZFS-Pools, in denen ich die Einhängepunkte verwendet habe.

Answer 1

Einige Hintergrundinformationen zum Problem

Nach einigem Recherchieren und Ausprobieren fand ich heraus, dass ZFS die Mount-Punkte verwendet. Meine Theorie stimmte also: Mount-Punkte sind nicht statisch wie Laufwerksbuchstaben in Windows. Stattdessen weist Linux sie in der Reihenfolge zu, in der sie beim Booten erkannt werden. Das Hinzufügen oder Entfernen von Festplatten kann die Mount-Punkte vermischen.

Einfaches Beispiel:

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

Nun fügen wir ein neues Laufwerk #4 hinzu. Es könnte so eingefügt werden:

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

Wenn wir vom Mount-Punkt abhängig sind, haben wir jetzt ein Problem: Unser System erwartet Laufwerk Nr. 2 in sdb, hat aber ein ganz anderes (Laufwerk Nr. 4) bekommen. Laut Arch-Wiki kann das sogar während eines normalen Bootvorgangs passieren,ohneirgendwelche Änderungen an den Festplatten.

Was können wir tun?

Nun, die Verwendung dieser Einhängepunkte scheint keine gute Idee zu sein. Wir sollten verwendenpersistente Blockgerätebenennungstattdessen, die mit udev verfügbar sind. Es sollte in jeder modernen Linux-Distribution verfügbar sein. Persistente Blocknamen verwenden keine neutralen Namen wie sdaoder sdb. Stattdessen werden Namen erstellt, die dauerhaft an das Laufwerk gebunden sind. Sie sind vergleichbar mit Laufwerksbuchstaben in Windows (ja, denken Sie daran, dass Laufwerksbuchstaben an Partitionen gebunden sind, während Blocknamen ein Laufwerk identifizieren, aber beide sind dauerhaft!).

by-idund by-uuidscheint am relevantesten, um dieses Problem zu lösen, aber es gibt auch andere. Eine ausführlichere Erklärung finden Sie auf der verlinkten Wiki-Seite von Arch. Es ist ein allgemeiner Artikel, der auch auf andere Distributionen zutreffen kann. Für dieses Problem ist es wichtig zu wissen, dass es sich um uuidseine Art generierte eindeutige ID handelt. Und wir können sie idsals besser lesbare Alternative verwenden, da sie festplattenspezifische Informationen wie Hersteller, Modell und Seriennummer verwenden.

ZFS

Alshier beschriebenwar es erforderlich, alle Pools zu exportieren und dann erneut zu importieren, allerdings mit dem -dSchalter. Er teilt zpool mit, wo nach Geräten gesucht werden soll:

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

Damit zpool statuslässt sich Folgendes überprüfen: Vor dem Export/Import sollten Sie die Einhängepunkte wie /dev/sdabei den Geräten sehen. Nach diesem Vorgang sollten sich diese in Disk-IDs ändern.

Normale Bände (optional)

Für mich war das nicht genug: ich habe eine zusätzliche Festplatte namensPufferfür Sachen wie ISO-Images. Keine wichtigen Daten, nur um meine SSD zu entlasten. Das war also ein klassisches ext3-Volume. Das hält meinen Server vom Booten ab, da hier genau das gleiche Problem auftritt: Der Mount-Punkt hat sich aufgrund der neuen Platten geändert, wodurch das Mounten fehlschlägt.

Ich habe das Problem gelöst, indem ich einfach dieses Laufwerk entfernt habe. Das war jedenfalls meine Idee, da die neuen Festplatten groß genug sind und ich durch weniger Festplatten etwas Energie sparen könnte. Dazu müssen wir den Speicher mithilfe einer /etc/pve/storage.cfgDatei aus Proxmox entfernen. In meinem Fall sieht der relevante Teil so aus:

dir: buffer
path /buffer
content iso

Nachdem wir es entfernt haben, müssen wir uns Folgendes ansehen /etc/fstab. Diese Datei mountet unser /bufferVolume, wo die Grundursache auftritt:

/dev/sdf /buffer ext3 rw 0 0

Wie Sie sehen, ist der Einhängepunkt /dev/sdfhier vorhanden.Wenn du die Platte nicht wie ich ablehnen willst, verwende hier einfach einen eindeutigen Einhängepunkt! Zum Beispiel /dev/disk/by-id. Dies ist ein Beispiel für persistente Blockgerätenamen. Sie werden auf der Grundlage geräteabhängiger Daten generiert. by-idBeispielsweise wird die Seriennummer der Hardware verwendet. So können wir sogar zwei gleiche Festplatten gerätespezifisch erstellen. Weitere Hintergrundinformationen finden Sie im ersten Absatz.

In meinem Fall verhindert das einfache Entfernen dieser Zeile, dass Linux meine Festplatte mountet. Wenn Sie mehrere Volumes haben, müssen Sie diese Schritte für jedes einzelne wiederholen, um sicherzustellen, dass nach einem Neustart keine Probleme auftreten.