Dies ist nicht dasselbe wie das Importieren eines Pools aus einem abgestürzten System, da das System nicht abgestürzt ist. Das Betriebssystem ist in Ordnung (auf einem anderen Pool/Laufwerkssatz/SATA-Bus).
Ich möchte vor dem Neustart einige wichtige Dateien kopieren (und dafür sorgen, dass das Ergebnis nicht sauber ist und keine intelligenten Hände in der Nähe eines unterversorgten Remote-Rechenzentrums eines Clients sind).
In diesem Fall ging ein USB-Caddy verloren und wurde dann wieder angeschlossen (Stromausfall/Störung), aber ZFS denkt, dass der Pool gemountet bleibt, aber alle IOs dazu verkeilen sich – aus sdd und sde sind jetzt sdf und sdg geworden.
Der Pool wurde über /dev/disk/by-id gemountet, aber diese IDs sind natürlich dieselben (und zeigen in /dev jetzt auf sd[fg]) und der alte Pool wurde nicht exportiert.
Jeder Zpool-Befehl bleibt hängen, da ich davon ausgehe, dass er /dev/sdd und sde berührt, wodurch dann die gesamte Shell hängen bleibt (jetzt bei meiner 10. Bash-Shell in Bildschirmfenstern ...).
Das Array funktioniert jedoch – dd if=/dev/sdf1 of=/dev/nullfunktioniert einwandfrei und iostat zeigt mir IO auf diesem Laufwerk an (dasselbe gilt für sdg). Das Laufwerk ist also ohne Blockieren lesbar.
Aber jeder Zpool-Befehl zpool import -Nd /dev/sdf1 poolname newpoolnameberührt auch nur irgendwo in der SD-Welt etwas und verkeilt sich.
Welchen Zpool-Importbefehl kann ich ausführen, damit auf gar keinen Fall versucht wird, ein anderes Laufwerk zu berühren? zpool import -d /dev/sdf1 -N newname(oder „alterName, neuerName“) blockiert einfach.
Ein letzter Ausweg könnte darin bestehen, das gesamte Laufwerk als Rohimage auf ein anderes System zu übertragen und dann dort mit Zpool herumzuspielen (über Loop-Geräte), aber das Senden von 4 TB wird ewig dauern.