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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 616392
Url: https://administrator.de/contentid/616392
Ausgedruckt am: 20.11.2024 um 17:11 Uhr
2 Kommentare
Neuester Kommentar
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.
