norman Posted November 21, 2020 #1 Posted November 21, 2020 Hallo, mir sind jetzt mehrfach Festplatten abgestürzt , woran kann das liegen ? die platten werden als "normal" angezeigt und SMART sieht für mich auch unauffällig aus. nach reboot des DSM kann ich die platten wieder hinzufügen und den Speicherpool reparieren. DSM: 6.2.2U4 ESXi 6.0 LSI 9217 als passthrouh mit 8 festplatten in ICY BOX, IB-2281MSK (Backplane für 8x 2,5" HDD/SSD) 1 pool mit raid6 zur anderen: die performance ist insgesamt recht wechselhaft. oft geht das volume auf 100% last obwohl die einzelnen platten geringe last haben. ich bin mir nicht sicher ob ein hardware Raid das nicht doch besser könnte. Quote
haydibe Posted November 21, 2020 #2 Posted November 21, 2020 (edited) Da Fallen mir zwei mögliche Ursachen ein: Unterversorgung der Platten mit Strom oder defekte Kabel Im Storage Manager im Bereich HDD/SSD, lohnt es sich bei jeder Platte mal "Health Info" anzusehen und dort den "Drive Reconnection Count". Sobald da bei auch nur einem Laufwerk die Zahl > 0 ist (und sich evtl. auch noch weiter erhöht) würde ich dringend die Verkabelung wechseln und/oder ein größerees Netzteil einbauen. Achte darauf das die Sata-Stromkabel von unterschiedlichen "Hauptsträngen" vom Netzteil abgehen. Minderwertige Verlängerungskabel können zu Problemen führen. Defekte MiniSAS Kabel können hier ebenfalls ihren Anteil tun. Ich hab bei mir zwichen 400-500mb/s Transferrate zwischen zwei SHR1 Volumes an einem LSI-9211 mit Direct-IO auf ESXi6.7 Edited November 21, 2020 by haydibe 1 Quote
IG-88 Posted November 21, 2020 #3 Posted November 21, 2020 (edited) generell lohnt auch ein blick in die logs um zu sehen was dort an meldugen steht wenn es schon mehrfach vor kam dann lohnt auch eine statistische betrachtung die strom und sas versorgung ist in 2 x 4 geteilt, wenn das problem immer auf einer 4er seite ist dann sind es ziemlich sicher kabel probleme, wenn es sich verteilt dann kann man aber leider nicht viel sagen, es könnte dann auch noch an den kabeln liegen oder am netzteil (selbst unverträglichkeiten platte/controller sind nicht auszuschließen) ganz allgemein ziehen 2.5" platten nicht so viel strom aber es kann trotzdem am netzteil liegen das log könnte auch aufschluss geben ob die platten im laufenden betrieb ausfallen oder evtl. nur beim hochfahren probleme machen auf grund von alten threads würde ich 1.04b 918+ vermuten und da drängt sich auch das disk hibernation problem auf das erst bei 6.2.3 aufgefallen ist aber schon immer existiert, also nachsehen ob die aktiv ist und abschalten, evtl. auf neue extra.lzma mit 6.2.3 umstellen (keine temp und smart infos) oder auf 3617 wechseln https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ erste priotität (nach disk hibernation abstellen) sollte aber ein backup haben, wenn man hier weiter rumspielt können auch schnell mal mehr als 2 platten aus dem raid fallen Edited November 21, 2020 by IG-88 1 Quote
Chili Posted November 23, 2020 #4 Posted November 23, 2020 On 11/21/2020 at 11:57 AM, IG-88 said: (nach disk hibernation abstellen).... Das war mein erster Gedanke. Die Symptome sprechen eine deutliche Sprache. Das Aufwachen der Platten aus dem Ruhezustand dürfte hier das Problem sein. Ich hatte meinen Dell H310 (auch LSI) genau deswegen verkauft und bin auf die JMB585 umgestiegen. Quote
IG-88 Posted November 23, 2020 #5 Posted November 23, 2020 6 minutes ago, Chili said: Die Symptome sprechen eine deutliche Sprache. Das Aufwachen der Platten aus dem Ruhezustand dürfte hier das Problem sein. Ich hatte meinen Dell H310 (auch LSI) genau deswegen verkauft und bin auf die JMB585 umgestiegen. bei einer (gehackte) appliance wie xpenologie ist es manchmal einfacher die probleme durch angepasste hardware zu umgehen, ist zwar nicht der "viel feind viel ehr" weg aber in sachen zeit versenken der effektivere weg mit 3617 ist lsi sas sicher zu betreiben, mit der 918+ geht das im moment nicht so wirklich, ich rätsel ja immer noch warum das erst so spät aufgefallen ist aber vermutlich haben viele mit lsi eher ältere cpu's und xeon's benutzt und da ist 3615/17 der normale weg, 918+ kommt erst jetzt in den fokus da modernere xeon's auch qsv haben und m.2 nvme ein thema wird (imho eigentlich nur nützlich bei 10G netzwerk) ich habe auch lsi sas rausgeworfen, mit pcie 3.0 und dem jmb585 kommt man bei normalen nas größen ganz gut hin, nur bei vielen ssd's im system muss man nachrechnen aber die kann man in der regel einfach an die internen sata's hängen um die volle leistung zu bekommen Quote
norman Posted November 23, 2020 Author #6 Posted November 23, 2020 LSI und ruhemodus ist ein guter tip. kann das ganze evtl mit dem wechsel der plattform zu tun haben ? wechsel von xeon e3-1225v3 ( HP z230 ) ---> zu xeon e5-2660v2 (HP z420) macht der wechsel von 3615 zu 3617 auf e5-2660v2 sinn ? 3617 ist ja für xeon v4 Quote
norman Posted November 24, 2020 Author #7 Posted November 24, 2020 (edited) die Testinstallation mit 3617xs/DSM 6.2.3-25426 unter vmware auf e5-2660v2 (HP z420) läuft soweit. hoffe nur es zerlegt mir das raid nicht, wenn ich den LSI in die neue 3617xs VM durchreiche. Einstellungen aus grub.cfg habe ich übernommen. aktuelle extra.lzma 0.11.2 ist eingebunden. log sieht ok aus. was hat es mit der jetzt sichtbaren 50mb synoboot platte auf sich, muss man sich daran stören oder einfach ignorieren ? 3617xs.txt Edited November 24, 2020 by norman Quote
IG-88 Posted November 25, 2020 #8 Posted November 25, 2020 (edited) On 11/24/2020 at 2:10 PM, norman said: was hat es mit der jetzt sichtbaren 50mb synoboot platte auf sich, muss man sich daran stören oder einfach ignorieren ? mit der 3. option im grub gebootet? afair sollte der loader am ersten sata controller hängen und alle weiteren platten an einem zweiten sata controller edit: versuch mal das hier https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ Edited November 25, 2020 by IG-88 Quote
norman Posted December 1, 2020 Author #9 Posted December 1, 2020 (edited) ich hab die VM nochmal neu aufgesetzt mit einem eigenen H220 controller und das ganze läuft bis zum update der extra.lzma auf extra3617_v0.11.2_test.zip :: Loading module ata_piix[ 10.567218] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 sieht nicht gut aus. habe ich eine falsche version erwischt ? würde eigentlich schon gerne mit aktuellen treibern starten wenn ich das system neu in betrieb nehme. um die eSATA kümmere ich mich anschließend, sind im Moment ganz praktisch zum extra.lzma tauschen könnte die controller firmware P20 eine rolle bei den platten abstürzen spielen oder war das nur bei DSM 5.x ? logfile.txt Edited December 1, 2020 by norman Quote
IG-88 Posted December 1, 2020 #10 Posted December 1, 2020 3 hours ago, norman said: : Loading module ata_piix[ 10.567218] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 sieht nicht gut aus. der treiber ist for intel sata im ide mode, den brauchst du sicher nicht, die von mit neu compilirte version hat noch nie funktioniert, ich hatte die version von jun's übernommen die wohl mit 6.2.0 funktionirt haben muss, sollte der treiber problem machen fliegt er raus, der ist für >8 jahre alte hardware und wenn es sein muss kann man auch einen pcie ahci controller in einen pcie slot stecken und das onboard zeug abschalten im falle deiner vm prüf doch mal ob da irgendwelche ide oder intel chipset sata hardware im spiel ist und entferne das aus der vm, hier gibts viele die esxi nutzen und ich habe jetzt nicht mitbekommen das die alle massich probleme mit dem ata_piix treiber haben, müsste also was an deiner vm sein Quote
norman Posted December 1, 2020 Author #11 Posted December 1, 2020 (edited) nichts auffällig in der VM ( cdrom und floppy gelöscht ) , vielleicht der C602 Chipsatz morgen mal bios paar bios einstellungen testen Edited December 1, 2020 by norman Quote
norman Posted December 2, 2020 Author #12 Posted December 2, 2020 (edited) ich hab jetzt auf einem anderen vmware server das ganze nochmal nachgestellt. wenn ich nach der DSM installation auf extra3617_v0.11.2_test wechsle das gleiche problem. wenn ich schon vor DSM installtion die treiber tausche , geht die installation noch , beim ersten reboot ist dann ende kann es an vmware 6.0 liegen ? mir fällt sonst nichts mehr ein. Edited December 2, 2020 by norman Quote
IG-88 Posted December 2, 2020 #13 Posted December 2, 2020 3 hours ago, norman said: kann es an vmware 6.0 liegen keine ahnung, aber die 6.0 ist schon aus dem support und bekommt keine sicherheitsupdates mehr, durchaus ein grund was neueres zu verwenden (zumal man das kostenloas bekommt) die vm hat auch ein bios, evtl. schau mal da drin nach ob es etwas in richtung ahci/ide gibt Quote
norman Posted December 3, 2020 Author #14 Posted December 3, 2020 (edited) ich hab jetzt folgendes gemacht - andere hardware -neue installation esx 6.7 - neuer download synoboot.img & treiber - treiber eingebunden , grub.cfg unverändert - VM von hand angelegt. ( alles neu ) - erster boot bis zum installations assistenten ok - installation DSM soweit alles OK erster reboot >>> :: Loading module ata_piix[ 2.421026] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 2.421819] IP: [<ffffffffa033938a>] piix_set_timings+0x3a/0x250 [ata_piix] [ 2.421822] PGD 37902067 PUD 3791f067 PMD 0 [ 2.421825] Oops: 0000 [#1] SMP wenn ich die treiber zurück tausche ( stand: 1.8.2018) , bootet 6.2.3.24426 Edited December 3, 2020 by norman Quote
IG-88 Posted December 3, 2020 #15 Posted December 3, 2020 11 hours ago, norman said: ata_piix ich habe grade den treiber in 11_2 und den aus jun's orginal extra.lzma verglichen, keine unterschied, ist die gleiche datei müsste dann also an der reihenfolge liegen wie es galaden wir ... ok, ich have mit die rc.modules von jun angesehen, da wird die ata_piix garnicht geladen (obwohl sie in der extra.lzma drin ist) das erklärt warum der fehler bei jun's alter extra.lzma nicht passiert dann versuch es doch mal mit jun's, die neueren treiber die in meiner sind wären für esxi unerheblich und der vmxnet3 treiber sollte auch in jun's extra.lzma mit 6.2.3 laufen ich werden dann in der nächsten extra.lzma den ata_piix treiber entfernen Quote
norman Posted December 3, 2020 Author #16 Posted December 3, 2020 (edited) mir gehts primär um einen aktuellen treiber für LSI controller, der wird per passthrough betrieben. oder würdest du den dann besser einzeln nachladen ? ( hab da mal was gelesen ) Edited December 3, 2020 by norman Quote
IG-88 Posted December 4, 2020 #17 Posted December 4, 2020 3 hours ago, norman said: oder würdest du den dann besser einzeln nachladen ? ( hab da mal was gelesen ) ich glaube nicht das das mit sowas geundlegendem gehen würde, ohne den treiber keine platten und keine raids man müsste die rc.modules anpassen und den ata_piix daraus löschen Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.