wie bekomme ich die disk 6429... hier raus? die ist eigentlich ersetzt (war vorher die sdd1). Hätte jetzt in meiner naivität gedacht
Code:
zpool remove backup-storage 6429726373323778672
--> cannot remove 6429726373323778672: operation not supported on this type of pool
würde das entfernen aber wei man sieht kommt eine Fehlermeldung, Dir mir nicht wirklich was sagt. Die platte ist schon ersetzt worden, aber wie bekomme ich die Leiche (kam nach einem reboot) da jetzt weg?
Es kann gut sein, dass nach einem Reboot jetzt eine andere Disk sdd ist.
Wenn deine neue Disk als unbenutzt unter Disks auftaucht, einfach den replace durchführen.
Das hatte ich nat auch probiert - aber die neue disk ist ja schon drin (sdd1). Außerdem findet er keine disk mit dem random/alten devicenamen (gibt es ja auch nicht).
zpool replace backup-storage 6429726373323778672
cannot open '6429726373323778672': no such device in /dev
must be a full path or shorthand device name
Ich vermute mal das derjenige, der das reparieren wollte, einfach die Platte bei Fehler getauscht hat und dann wurde der Rechner rebootet. In der history ist kein replace zu sehen nur ein scrub (mitten in der nacht) und ein zpool import -c /etc/zfs/zpool.cache -aN (vermute mal das passiert immer beim reboot?) sieht zumindest zeitlich so aus.
lsblk -o NAME,UUID,FSTYPE,FSUSE%,TYPE,SIZE,MOUNTPOINT,MODEL
NAME UUID FSTYPE FSUSE% TYPE SIZE MOUNTPOINT MODEL
sdb disk 279.4G LOGICAL_VOLUME
├─sdb1 14973201642163664498 zfs_member part 279.4G
└─sdb9 part 8M
sdc disk 279.4G LOGICAL_VOLUME
├─sdc1 14973201642163664498 zfs_member part 279.4G
└─sdc9 part 8M
sdd disk 279.4G LOGICAL_VOLUME
├─sdd1 14973201642163664498 zfs_member part 279.4G
└─sdd9 part 8M
sde disk 279.4G LOGICAL_VOLUME
├─sde1 14973201642163664498 zfs_member part 279.4G
└─sde9 part 8M
sdf disk 279.4G LOGICAL_VOLUME
├─sdf1 14973201642163664498 zfs_member part 279.4G
└─sdf9 part 8M
hmm halt da fehlt sdg ich muss mal selber an die kiste, irgendwas ist da faul.
Durch den Reboot sind die neu durchnummeriert worden. Das ist ganz normal.
Also sollte die getauschte Disk als sdg auftauchen.
In einem RaidZ kannst du keine Disks entfernen oder hinzufügen, nur ein weiteres RaidZ vdev.
Also neue Disk noch einmal kontrollieren und dann replace durchführen.
Ja, das ist auch nur ein Platzhalter mit einer randomID, damit man im pool altedisk bzw. den slot beim replace definieren kann.
Die Frage ist auch, ob das initial ein raidz1 mit 5 oder 6 disks war/sein sollte. Wenn du sagst, dass sdg fehlt, rate ich mal auf 6 disks. Edit: Dann könnte es sein, dass der pool unbemerkt auch nur mit 5 erstellt wurde. (Das sollte dann am Anfang von zpool history stehen) War Blödsinn, steht ja da mit 6 Stück.
Und ja, ich vermute auch, dass die neue disk dann unter anderem Namen auftaucht. Was aber nicht schlimm ist, denn ZFS schreibt an Anfang und Ende Metadaten (disk oder Partition), damit es ganz sicher zuordnen kann und man einen pool auch wild zerwürfelt importieren kann.
gerade mal im kernel log gewühlt, da im ILOM 6 disks drin sind linux aber nur 5 sieht.
hpsa 0000:05:00.0: addition failed -19, device not added
da scheint es noch ein kleines problem mit dem Kontroller und Kernel zu geben. Das muss zuerst gelöst werden. Wenn die dann da ist, sollte danach das mit dem replace hoffentlich auch klappen (und ja klaro zwei disks beim replace kommando, war eine reine Verzweifelung, nur mit der random id, um zu sehen was passiert, dachte da noch, dass alle disks da sind).
Nur kurzes update - das problem mit dem HP controller scheint es wohl auch bei RHEL etc. zu geben. Sprich manche Platten werden einfach nicht sauber eingebunden. Das issue ist also weder ZFS noch Proxmox verursacht.
Sondern HP<-> kernel in Kombi mit dem vor der Tastatur, der das nicht erkannt hatte
HP 410i. Ist eine HP G7 (also recht alt). das ZFS hatte wurde wohl auch nur mit krücke über logical volume und cache aus eingerichtet. Ich weiss sollte man mit ZFS nur im HBA mode... hat aber eine ganze Weile funktioniert und ich sehe das Problem immer noch eher bei der Erkennung/einbindung der neuen Disk.
Es werden acht platten erkannt.
[ +0.000008] hpsa 0000:05:00.0: scsi 2:0:1:0: masked Direct-Access HP DG0146FARVU PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000007] hpsa 0000:05:00.0: scsi 2:0:2:0: masked Direct-Access HP EG0300FBDBR PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000006] hpsa 0000:05:00.0: scsi 2:0:3:0: masked Direct-Access HP EG0300FBDBR PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000005] hpsa 0000:05:00.0: scsi 2:0:4:0: masked Direct-Access HP EG0300FCVBF PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000006] hpsa 0000:05:00.0: scsi 2:0:5:0: masked Direct-Access HP EG0146FAWHU PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000006] hpsa 0000:05:00.0: scsi 2:0:6:0: masked Direct-Access HP EG0300FBDBR PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000006] hpsa 0000:05:00.0: scsi 2:0:7:0: masked Direct-Access HP EG0300FAWHV PHYS DRV SSDSmartPathCap- En- Exp=0
[ +0.000006] hpsa 0000:05:00.0: scsi 2:0:8:0: masked Direct-Access HP EG0300FAWHV PHYS DRV SSDSmartPathCap- En- Exp=0
Zwei gehen in ein RAID und 6 in logical volume für ZFS.
Für scsi 2:1:0:3? kommt dann aber im syslog
[ +0.000640] hpsa 0000:05:00.0: addition failed -19, device not added.
Die meldung habe ich hier (finde den Beitrag nicht mehr) auch schon gefunden und es wurde immer auf HP support verwiesen.
Vermutlich werden wir für die alten kisten dann eher wieder hardware array und ext4 einsetzen.
@endurance
Bei dem P410 kannst du keinen HBA Mode machen. vermutlich habt ihr auch jeweils ein Raid0 erstellt.
Das Raid0 der defekten Disk muss gelöscht werden und neu angelegt werden, damit der Host die neue Disk erkennt.
Moin yepp - die alte kiste kann kein HBA und deswegen hat der Kollege wie vermutet (und steht auch so im log) R0 pro platte eingerichtet. R0 verwenden wir sonst nie von daher naiver Weise davon ausgegangen, dass man hier auch einfach die Platte tauschen kann und dann richtet sich das von alleine. Nach löschen neu anlegen ging dann auch ZFS.
Aber so macht das keinen Sinn, wir werden die alten Kisten dann eher ausmustern bzw. mit HW raid betreiben (ohne ZFS)
Moin yepp - die alte kiste kann kein HBA und deswegen hat der Kollege wie vermutet (und steht auch so im log) R0 pro platte eingerichtet. R0 verwenden wir sonst nie von daher naiver Weise davon ausgegangen, dass man hier auch einfach die Platte tauschen kann und dann richtet sich das von alleine. Nach löschen neu anlegen ging dann auch ZFS.
Aber so macht das keinen Sinn, wir werden die alten Kisten dann eher ausmustern bzw. mit HW raid betreiben (ohne ZFS)
Bei dem Alter der Hardware lohnt sich der Austausch ganz schnell durch den eingesparten Strom. Also am besten mit HBA oder einem modernen Raid Controller nutzen. Ab HPE Gen10 können die Smart Array einen sauberen Mixed Mode, dann kannst du Raid für das OS nutzen und alle anderen Disks werden sauber im HBA Mode durchgereicht.
Ab HPE Gen10 können die Smart Array einen sauberen Mixed Mode, dann kannst du Raid für das OS nutzen und alle anderen Disks werden sauber im HBA Mode durchgereich
Yepp - gerade eine GEN10 mit Mirrored OS Bootdisks und HBA für ZFS aufgesetzt. Das erste mal auch auf AMD gesetzt. Das funktioniert ohne Probleme.
Das Proxmox setup ist noch im Testaufbau um von VMWare (aber die freie Version) weg zu kommen. Challenge ist ein platten und netzwerk setup das sich auf möglichst allen Rechnern umsetzen lässt - ist bei bestehendem Umfeld etwas längerer Prozess und wir lernen hier auch noch.
Yepp - gerade eine GEN10 mit Mirrored OS Bootdisks und HBA für ZFS aufgesetzt. Das erste mal auch auf AMD gesetzt. Das funktioniert ohne Probleme.
Das Proxmox setup ist noch im Testaufbau um von VMWare (aber die freie Version) weg zu kommen. Challenge ist ein platten und netzwerk setup das sich auf möglichst allen Rechnern umsetzen lässt - ist bei bestehendem Umfeld etwas längerer Prozess und wir lernen hier auch noch.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
