Mr.Mito
Admiral, Altweintrinker
Hallo in die Runde,
Meine Hoffnung ist gering, aber vielleicht ist hier ja doch ein User, der beruflich mit dem Krempel zu tun hat.
Folgende Situation:
StoragePool aus 5 Platten / Parity / NumberOfColumns 3 / UseMaximumSize / ProvisioningType fixed
Eine der Platte wurde dem Pool entnommen und komplett überschrieben. Die Platte wurde vorher dem Pool nicht als retired gemeldet (war vielleicht dumm
).
Nun ist es so, dass ich verzweifelt versuche die gleiche und leere Platte dem Pool wieder hinzuzufügen. Obwohl die Platte leer ist (100% leer, form unit Hitachi) wird sie dem Pool erneut zugeordnet, denke mal durch die S/N.
Wenn ich die Platte mit einem reset-physicaldisk zurücksetze ist soweit auch alles gut. Er listet mir alle 5 Platten im Pool mit "ok", aber den Pool an sich weiterhin als degraded. Was ja auch korrekt ist. Will ich allerdings mit einem "Repair-VirtualDisk" den Pool fixen spuckt er mir den glorreichen Fehler "Not enough available capacity".
Jetzt kommt aber das wirklich komische. Ich habe die Platte also wieder gekillt (diesmal vorher retired gesetzt) usw. und sie erneut mit reset-physicaldisk in den Pool gebracht. Danach habe ich wieder den Zustand Platten OK (Healthy), Pool degraded. Der auto repair ist auch in der Joblist, aber mit suspended. Starte ich nun neu, passiert folgendes:
Ich sehe die Poolplatte in der Datenträgerverwaltung als Einzellaufwerk (
), kann damit natürlich nichts machen (alles ausgegraut) und der Versuch das Laufwerk erneut mit reset.physicaldisk zurück zu setzen scheitert mit:
"Reset-PhysicalDisk : The operation failed with return code 8"
Zu dem Code finde ich mit google genau gar nichts.
Das Laufwerk wird in dem Zustand auch in Diskpart gelistet und ich kann es erneut "clean"en um auf den status quo zurück zu kommen.
Jemand eine Idee? Sieht für mich nach bug aus ... ist nur die Frage wie ich ihn umschiffen kann.
Eine weitere Platte um diese einzubinden und dann die "Problemplatte" retired zu removen habe ich nicht. Selbst wenn, die 10 SATA Ports sind alle voll. Auswerfen bevor Ersatz drin ist darf man bei den Pools ja nicht...
MfG
Mito
Meine Hoffnung ist gering, aber vielleicht ist hier ja doch ein User, der beruflich mit dem Krempel zu tun hat.

Folgende Situation:
StoragePool aus 5 Platten / Parity / NumberOfColumns 3 / UseMaximumSize / ProvisioningType fixed
Eine der Platte wurde dem Pool entnommen und komplett überschrieben. Die Platte wurde vorher dem Pool nicht als retired gemeldet (war vielleicht dumm

Nun ist es so, dass ich verzweifelt versuche die gleiche und leere Platte dem Pool wieder hinzuzufügen. Obwohl die Platte leer ist (100% leer, form unit Hitachi) wird sie dem Pool erneut zugeordnet, denke mal durch die S/N.
Wenn ich die Platte mit einem reset-physicaldisk zurücksetze ist soweit auch alles gut. Er listet mir alle 5 Platten im Pool mit "ok", aber den Pool an sich weiterhin als degraded. Was ja auch korrekt ist. Will ich allerdings mit einem "Repair-VirtualDisk" den Pool fixen spuckt er mir den glorreichen Fehler "Not enough available capacity".
Jetzt kommt aber das wirklich komische. Ich habe die Platte also wieder gekillt (diesmal vorher retired gesetzt) usw. und sie erneut mit reset-physicaldisk in den Pool gebracht. Danach habe ich wieder den Zustand Platten OK (Healthy), Pool degraded. Der auto repair ist auch in der Joblist, aber mit suspended. Starte ich nun neu, passiert folgendes:
Ich sehe die Poolplatte in der Datenträgerverwaltung als Einzellaufwerk (

"Reset-PhysicalDisk : The operation failed with return code 8"
Zu dem Code finde ich mit google genau gar nichts.

Jemand eine Idee? Sieht für mich nach bug aus ... ist nur die Frage wie ich ihn umschiffen kann.

MfG
Mito
Zuletzt bearbeitet: