2
Seagate ES.3 ST4000NM0023 Linux (Debian) Proxmox Problem
Hallo Zusammen,
möglicherweise kann mir jemand von euch weiterhelfen.
Mein Aktuelles Problem Bezieht sich speziell auf die Seagate Constellation ES.3 4TB ST4000NM0023. Diese stecken an einem 12 Bay Backplane von Supermicro, weiter zu einem LSI 9300 8i (2 Leitungen) angebunden über PCI-e 3.0 x8.
Als Grundsystem läuft ein Proxmox 6.2-12 das bringt mir in der Ausgabe folgende Fehler:
blk_update_request protection error (Siehe Bild)
dies aber auch Ständig für alle 10 Platten, die dran hängen.
Es ist weder über Proxmox WebGUI noch über fdisk oder sonstiges möglich sinnvoll mit den HDDs zu kommunizieren GPT Tabelle wird nicht erkannt, kann aber auch nicht geschrieben werden. SMART Infos können aber ohne Probleme gelesen werden.
Zuvor HP 600gb 10K Platten dran gehabt absolut keine Probleme. GPT schreiben, Formatieren - Raid einrichten, Performance, alles problemlos. (das aber nur zwischendurch)
Nun zum spannenden Thema. Ich habe mir eine Win10 VM erzeugt, LSI9300 via PCI-e Passthrough an die Windows VM weitergegeben - Keinerlei Probleme GPT lässt sich schreiben, Raid 0 (Software) läuft und die Performance 1,2GB/s lesen & 970MB/s schreiben. Alles super also soweit.
Also zum gegenprüfen das Ganze noch einmal mit einem Ubuntu 20.04 & 20.10 getestet. Selber Fehler wie bei Proxmox. fdisk, GParted und sonstiges schlägt alles fehl.
Ziel ist es die 10x 4TB Platten via ZFS als Raid Z2 zusammen zu werfen und anschließend einige VM HDDs von PROXMOX darauf laufen zu lassen. Das aber nur am rande dazu.
Also eine Inkompatibilität vom Controller hab ich quasi ausgeschlossen, alles deutet für mcih auf ein HDD zu Linux (Debian) Problem.
Aber: Enterprice HDDs inkompatibel mit Linux ist für mich auch ein nicht denkbarer Zustand, von daher bin ich auf eure Hilfe angewiesen.
möglicherweise kann mir jemand von euch weiterhelfen.
Mein Aktuelles Problem Bezieht sich speziell auf die Seagate Constellation ES.3 4TB ST4000NM0023. Diese stecken an einem 12 Bay Backplane von Supermicro, weiter zu einem LSI 9300 8i (2 Leitungen) angebunden über PCI-e 3.0 x8.
Als Grundsystem läuft ein Proxmox 6.2-12 das bringt mir in der Ausgabe folgende Fehler:
blk_update_request protection error (Siehe Bild)
dies aber auch Ständig für alle 10 Platten, die dran hängen.
Es ist weder über Proxmox WebGUI noch über fdisk oder sonstiges möglich sinnvoll mit den HDDs zu kommunizieren GPT Tabelle wird nicht erkannt, kann aber auch nicht geschrieben werden. SMART Infos können aber ohne Probleme gelesen werden.
Zuvor HP 600gb 10K Platten dran gehabt absolut keine Probleme. GPT schreiben, Formatieren - Raid einrichten, Performance, alles problemlos. (das aber nur zwischendurch)
Nun zum spannenden Thema. Ich habe mir eine Win10 VM erzeugt, LSI9300 via PCI-e Passthrough an die Windows VM weitergegeben - Keinerlei Probleme GPT lässt sich schreiben, Raid 0 (Software) läuft und die Performance 1,2GB/s lesen & 970MB/s schreiben. Alles super also soweit.
Also zum gegenprüfen das Ganze noch einmal mit einem Ubuntu 20.04 & 20.10 getestet. Selber Fehler wie bei Proxmox. fdisk, GParted und sonstiges schlägt alles fehl.
Ziel ist es die 10x 4TB Platten via ZFS als Raid Z2 zusammen zu werfen und anschließend einige VM HDDs von PROXMOX darauf laufen zu lassen. Das aber nur am rande dazu.
Also eine Inkompatibilität vom Controller hab ich quasi ausgeschlossen, alles deutet für mcih auf ein HDD zu Linux (Debian) Problem.
Aber: Enterprice HDDs inkompatibel mit Linux ist für mich auch ein nicht denkbarer Zustand, von daher bin ich auf eure Hilfe angewiesen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 616392
Url: https://administrator.de/contentid/616392
Printed on: April 25, 2024 at 15:04 o'clock
2 Comments
Latest comment
Nabend,
hier beschreibt ein Mitarbeiter von Mellanox ein ähnliches Phänomen im Linux-SCSI Treiber: https://lore.kernel.org/linux-scsi/1576078562-15240-1-git-send-email-isr ...
Ich würde vermuten, dass im Unterschied zu den "alten" HP-Platten jetzt 4k Sektoren verwendet werden und der Treiber damit nicht richtig klarkommt.
Ggf. mal
a) ein Firwareupgrade des LSI Controllers durchführen
b) mal nach einem neueren Treiber für den Controller suchen bzw. ein entsprechendes Kernel-Update durchführen.
Gruß
cykes
hier beschreibt ein Mitarbeiter von Mellanox ein ähnliches Phänomen im Linux-SCSI Treiber: https://lore.kernel.org/linux-scsi/1576078562-15240-1-git-send-email-isr ...
Ich würde vermuten, dass im Unterschied zu den "alten" HP-Platten jetzt 4k Sektoren verwendet werden und der Treiber damit nicht richtig klarkommt.
Ggf. mal
a) ein Firwareupgrade des LSI Controllers durchführen
b) mal nach einem neueren Treiber für den Controller suchen bzw. ein entsprechendes Kernel-Update durchführen.
Gruß
cykes
Hallo,
besten Dank schon einmal für die schnelle Antwort. Für den Controller habe ich noch ein Update von 16.0.01 auf 16.0.10 gefunden. Ich musste 3 mal gucken, bevor ich es realisiert habe. Leider trotzdem keine Besserung.
Treiber für den Controller gesucht, leider auch erfolglos. Er war schon vorhanden, trotzdem drüber gebügelt und keine Besserung.
Die Seagate ES.3 Platten nutzen noch 512B Sektoren und noch keine 4k. habe gerade auch noch einmal geschaut, die vorherigen waren Toshiba AL13SEB600. Auch 512B Sektoren.
besten Dank schon einmal für die schnelle Antwort. Für den Controller habe ich noch ein Update von 16.0.01 auf 16.0.10 gefunden. Ich musste 3 mal gucken, bevor ich es realisiert habe. Leider trotzdem keine Besserung.
Treiber für den Controller gesucht, leider auch erfolglos. Er war schon vorhanden, trotzdem drüber gebügelt und keine Besserung.
Die Seagate ES.3 Platten nutzen noch 512B Sektoren und noch keine 4k. habe gerade auch noch einmal geschaut, die vorherigen waren Toshiba AL13SEB600. Auch 512B Sektoren.
