February 12, 20215 yr Hallo, Ich habe alle meine Festplatten von reiserfs zum xfs Dateisystem umgestellt. 1. Daten auf eine externe HD kopiert 2. Festplatte formatiert nach Anleitung 3. Daten zurück auf den Server Bei dem Ganzen habe ich die parity Platte deaktiviert um höchstmögliche Sschreibgeschwindigkeit zu haben 4. rebuild der parity Jetzt habe ich mitten bei der Wiederherstellung der parity Platte Lesefehler auf 4 von 10 Platten. Ich glaube sie sind überhaupt nicht mehr ansprechbar? Das komische ist, es sind genau die Platten die an einem anderen Controller hängen (Marvell 88SE9230). Zur Vervollkommnung der Geschichte muss ich erwähnen, dass ich vor Monaten den Prozessor von Pentium 3220T auf I5 4590T gewechselt habe und danach genau die Platten ebenfalls nicht erkannt wurden, bis ich irgendetwas in einer config geändert habe. Komischer Weise wurden die Platten an diesem Controller mit der alten CPU erkannt, mit der neuen nicht. Bei der Schnellsuche habe ich gerade leider nicht gefunden was es damals war. (habe es mir leider auch nicht gemerkt da es ja funktionierte nach ändern irgendeiner config auf dem boot-stick ich habe es gefunden: in der syslinux.cfg Zeile 8 geändert von "append initrd=/bzroot" --> "append initrd=/bzroot iommu=pt" Ich gehe jetz erst einmal von einem Zufall aus und es hat nichts mit der Umstellung des Dateisystems zu tun sondern irgendetwas mit dem Marvel-Controller in Verbindung mit der CPU. Soll ich die parity-Wiederherstellung abbrechen und neu booten um zu gucken ob der Server sich nur "verschluckt" hat? Eine System Log kann ich nicht aufrufen: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134139936 bytes) in /usr/local/emhttp/plugins/dynamix/include/Syslog.php on line 20 Ich weiß gerade nicht weiter.. edit: nach einem Neustart sind zwei von den vier Platten wieder im array aufgetaucht und es ließ sich die System Log abspeichern welche ich angehangen habe Grüße Mein UNraid: Model: N/A M/B: Gigabyte Technology Co., Ltd. Z87X-UD5H-CF Version x.x - s/n: To be filled by O.E.M. BIOS: American Megatrends Inc. Version 10e. Dated: 11/14/2017 CPU: Intel® Core™ i5-4590T CPU @ 2.00GHz HVM: Enabled IOMMU: Enabled Cache: 256 KiB, 1024 KiB, 6144 KiB Memory: 16 GiB DDR3 (max. installable capacity 32 GiB) Network: eth0: 1000 Mbps, full duplex, mtu 1500 eth1: interface down Kernel: Linux 4.19.107-Unraid x86_64 OpenSSL: 1.1.1d massengrab-syslog-20210212-1638.zip Edited February 16, 20215 yr by helgebernd
February 12, 20215 yr Community Expert Wenn du auf das Disk-Symbol klickst, erhältst du die Fehlermeldungen auch zu einzelnen Disks: Ansonsten kannst du die System Logs auch über Tools -> Diagnostics herunterladen. 26 minutes ago, helgebernd said: Marvell 88SE9230 Der hat einen Bug, der hier beschrieben ist: https://forums.unraid.net/topic/39003-marvell-disk-controller-chipsets-and-virtualization/ Lösung: - Config Editor installieren - /boot/syslinux/syslinux.cfg bearbeiten - Nach "label Unraid OS" die erste "append" Zeile suchen und am Ende dieser Zeile " iommu=pt" hinzufügen (also per Leertaste trennen) - Server neu starten Hier ein Screenshot: Bessere Lösung: Ersetz die Karte gegen eine mit einem JMB585 oder ASM1166 Controller
February 12, 20215 yr Author Danke für die schnelle Reaktion mgutt !! Ich habe mein damaliges Vorgehen wiedergefunden und im ersten Post bearbeitet. Zwei von den vier Platten sind auch wieder verfügbar nach einem Neustart. Der Controller ist auf dem Board und der Server lief jetzt seit 2014 mit dem Pentium g3220T und seit 2020 mit dem I54590T Warum lief der Server Monate lang ohne Probleme nach hinzufügen von iommu=pt und jetzt spinnt das Ding?
February 12, 20215 yr Community Expert 1 minute ago, helgebernd said: Warum lief der Server Monate lang ohne Probleme nach hinzufügen von iommu=pt und jetzt spinnt das Ding? In dem Thread berichten auch manche von eher zufälligen Ereignissen. Ich denke mal du hast noch ungenutzte PCIe Slots? Dann los, kauf dir eine SATA Karte https://de.aliexpress.com/item/32986459789.html (IOCrest ist ein guter Hersteller) https://de.aliexpress.com/item/4001263060833.html (Hersteller unbekannt, aber günstig)
February 12, 20215 yr Author 24 minutes ago, mgutt said: In dem Thread berichten auch manche von eher zufälligen Ereignissen. Ich denke mal du hast noch ungenutzte PCIe Slots? Dann los, kauf dir eine SATA Karte https://de.aliexpress.com/item/32986459789.html (IOCrest ist ein guter Hersteller) https://de.aliexpress.com/item/4001263060833.html (Hersteller unbekannt, aber günstig) Ich habe in der Tat PCIe Slots frei und eine SATA Karte ist auch unterwegs weil ich dieses neumodische mit Cache-Platte nun auch mal ausprobieren wollte...leider nur mit zwei Anschlüssen weil es bis eben ja noch alles funktionierte 😕 Ich werde mal so lange neustarten bis die Platten wieder da sind um wenigstens die Parity wieder herstellen zu können... muss ich "iommu=pt" bei Verwendung einer Sata-Karte dann wieder aus der syslinux.cfg entfernen? Edited February 12, 20215 yr by helgebernd
February 12, 20215 yr Author Platte 1-7 sind jetzt da, 8+9 wollen nicht gefunden werden. Wie kann ich denn auf die vorhandenen Daten zugreifen (ohne Ausbau)? Das array lässt sich ja nicht starten, da zwei platten fehlen?
February 12, 20215 yr Community Expert Naja, wenn die Platten nicht angezeigt werden, dann läuft der Treiber nicht. Evtl könntest du es mal mit einer älteren Unraid Version und einem anderen Stick probieren? Viellleicht geht es ja dann?! Oder mit der aktuellen 6.9 RC?!
February 12, 20215 yr Author Ich habe jetzt so lange neu gestartet bis alle Platten wieder da waren. Parity sync läuft erstmal wieder. Sata Karte ist bestellt. Muss dann "iommu=pt" wieder raus aus der syslinux.cfg, da ja kein Marvel-Controller mehr benutzt wird? Heißt das dann; Sata-Karte einbauen, Festplatten anschließen und alles ist wie vorher? UNraid erkennt dann die Zuordnung anhand der Seriennummern der Platte? Ein schönes Wochenende!
February 12, 20215 yr Community Expert 1 hour ago, helgebernd said: UNraid erkennt dann die Zuordnung anhand der Seriennummern der Platte? Jo 1 hour ago, helgebernd said: Muss dann "iommu=pt" wieder raus aus der syslinux.cfg Nein. Die Einstellung hat vom Prinzip nur Vorteile und keine Nachteile: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF Quote You should also append the iommu=pt parameter. This will prevent Linux from touching devices which cannot be passed through.
Archived
This topic is now archived and is closed to further replies.