Synology-Forum.nl
Firmware => Synology DSM 5.1 en eerder => Topic gestart door: v0LrAtH op 26 maart 2015, 09:03:34
-
Ik heb setup draaien met RS812 + RX410 (op DSM 5.0) met daarin 8 x 3TB schijven. 7 hiervan zitten in een RAID-6, terwijl er nog eentje los draait. Ik draai ondertussen al een 3-tal jaren met deze opstelling, en de afgelopen weken was er dan ook weer een schijf aan het sterven. Dit is reeds de 3e Seagate ST3000DM001 die sterft, dus niets nieuws onder de zon.
Nu heb ik, net zoals vorige keer, een nieuwe 3TB WD Red gekocht, deze geswapt met de brakke HDD, en de repair gestart. Echter na een paar uur is mijn Synology volledig vastgelopen (geen web interface, geen toegang via PuTTY, zelfs de aan-uit-knop werkte niet meer, reset heb ik moeten doen door de kabel uit te trekken). Na de reboot, heb ik alle services uitgeschakeld, maar weer diezelfde crash (de repair start automatisch terug). Daarna ook nog een 3e maal geprobeerd, met hetzelfde resultaat. Nu heb ik dus geen idee meer wat ik kan doen.
Het enige plan van aanpak lijkt me om te proberen upgraden naar DSM 5.1. En dan maar hopen dat de bug die mijn probleem veroorzaakt toevallig opgelost is. Echter om dit te doen, lijkt het me dat ik de repair zal moeten stoppen door de nieuwe HDD er terug uit te halen. Van daar mijn vragen:
- Is er ergens een log die mij informatie kan verschaffen over de vastlopers?
- Is het wel zo slim te proberen upgraden naar 5.1 met een Synology die niet stabiel draait?
- Enig ander idee hoe ik de vastlopers kan vermijden, en gewoon de repair voltooien, zonder de upgrade?
-
Tijdens een raid rebuild en een vastloper daarvan zou ik NOOIT een update gaan uitvoeren!
Dat lijkt mij echt vragen om nog meer moeilijkheden.
Contact opnemen met Synology lijkt mij veel verstandiger, wie weet kunnen zij vanaf afstand deze rebuild wel tot een goed einde brengen.
-
Dank je voor deze reactie, ik zal de optie van de upgrade naar DSM 5.1 schrappen. Ik ga straks de logs nog wat verder proberen te analyzeren, en ook nog meer stop proberen te zetten (file services), om toch maar deze repair tot een goed einde te brengen.
Mocht dat niet lukken, zal ik inderdaad proberen contact te nemen met Synology zelf.
Hopelijk lukt het om deze te redden. De kritische data zitten in de Cloud gebackupt, maar dit is maar circa 1TB van de 14TB. De overige 13TB (lokaal) backuppen zou een kostelijke zaak worden.
-
Ik heb op het forum wel vaker gelezen dat Synology vastlopers tot een goed einde kon brengen.
Het is natuurlijk geen garantie.
Zoveel data backuppen is ondoenlijk, ik weet er alles van.
-
Een backup nemen staat dan ook niet echt in de mogelijkheden. Dan zou ik nog eerder gaan voor de aanschaf van een RS815+ en een 4-tal nieuwe schijven (van 6TB). Dan ben ik meteen ook van de 16TB volume limiet verlost. Echter had ik gehoopt deze procedure nog een 2-tal jaren uit te stellen. Buiten het feit dat dit kostelijk is (en nog niet echt nodig), is het ook nog een gok of de RX410 met de RS815+ samen kan werken (al vind ik nergens een tegenindicatie, noch een bevestiging).
-
Heb je al eens geprobeert die nieuwe schijf eruit te halen en even aan/in een pc te hangen en de testsoftware van WD er op los te laten.
Het zou zo maar kunnen dat je nieuwe schijf een DOA is.
-
De repair was al enige uren bezig, ik zou de nieuwe schijf er nu niet zomaar weer uithalen.
-
Als de NAS al uit staat is dat geen enkel probleem. Hij begint toch sowieso volledig van voren af aan met de rebuild als je hem weer aan zet. Als je er maar voor zorgt dat bij de start van de NAS alle andere schijven wel aanwezig zijn, zodat je geen fout-op-fout krijgt.
Mijn gok zou dezelfde zijn als die van Ben(V), namelijk dat de nieuwe schijf een defect heeft en dat het rebuild proces daarop vastloopt.
-
Klopt, ik had erover heen gelezen dat de NAS uit staat.
Als deze draait zou ik de schijf er nu niet uithalen.
-
Ik zal hem allicht toch weer moeten stoppen met de kabel eruit te trekken. Ik wou vanochtend gewoon even de voortgang checken (naïef dat ik was ging ik er vanuit dat hij geen 3e keer gecrashed ging zijn), toen ik merkte dat ik weer geen toegang had via web interface of via PuTTY.
Straks als ik thuis kom, zal ik snel merken dat het weer zover is (vorige keren flikkerde enkel nog 1 van de 2 LAN ledjes (trunked), en werkte zelfs de power knop niet meer). Daarna snel de WD diagnostics erop los laten op mijn PC'tje. Ik hou jullie alvast op de hoogte.
-
Ik heb ondertussen de harde schijf terug verwijderd, en de machine is nu bezig aan z'n pariteitscontrole (circa 2% na 2 uur) terwijl hij gewoon degraded blijft. De scan op de harde schijf loopt ondertussen ook.
Het enige wat me zorgen baart is de logs van de machine, deze lijken te sturen op nog meer brakke schijven (als ik het met m'n beperkte kennis interpreteer):
Mar 25 22:29:27 RackStation kernel: [ 3019.040000] ata5.00: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:27 RackStation kernel: [ 3019.040000] ata5.01: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:27 RackStation kernel: [ 3019.050000] ata5.02: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:27 RackStation kernel: [ 3019.050000] ata5.03: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:27 RackStation kernel: [ 3019.060000] ata5.04: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:27 RackStation kernel: [ 3019.060000] ata5.00: exception Emask 0x100 SAct 0xf SErr 0x0 action 0x6 frozen
Mar 25 22:29:27 RackStation kernel: [ 3019.070000] ata5.00: dev err
Mar 25 22:29:27 RackStation kernel: [ 3019.070000] ata5.00: failed command: READ FPDMA QUEUED
Mar 25 22:29:27 RackStation kernel: [ 3019.080000] ata5.00: cmd 60/00:00:00:ef:e1/01:00:04:00:00/40 tag 0 ncq 131072 in
Mar 25 22:29:27 RackStation kernel: [ 3019.080000] res 41/40:00:f0:ef:e1/40:01:04:00:00/00 Emask 0x409 (media error) <F>
Mar 25 22:29:27 RackStation kernel: [ 3019.090000] ata5.00: status: { DRDY ERR }
Mar 25 22:29:27 RackStation kernel: [ 3019.100000] ata5.00: error: { UNC }
Mar 25 22:29:27 RackStation kernel: [ 3019.100000] ata5.00: failed command: READ FPDMA QUEUED
Mar 25 22:29:27 RackStation kernel: [ 3019.100000] ata5.00: cmd 60/00:08:00:f0:e1/01:00:04:00:00/40 tag 1 ncq 131072 in
Mar 25 22:29:27 RackStation kernel: [ 3019.100000] res 41/40:18:00:f2:e1/40:00:04:00:00/40 Emask 0x9 (media error)
Mar 25 22:29:27 RackStation kernel: [ 3019.110000] ata5.00: status: { DRDY ERR }
Mar 25 22:29:27 RackStation kernel: [ 3019.110000] ata5.00: error: { UNC }
Mar 25 22:29:27 RackStation kernel: [ 3019.120000] ata5.00: failed command: READ FPDMA QUEUED
Mar 25 22:29:27 RackStation kernel: [ 3019.120000] ata5.00: cmd 60/00:10:00:f1:e1/01:00:04:00:00/40 tag 2 ncq 131072 in
Mar 25 22:29:27 RackStation kernel: [ 3019.120000] res 41/40:18:00:f2:e1/40:00:04:00:00/40 Emask 0x9 (media error)
Mar 25 22:29:27 RackStation kernel: [ 3019.130000] ata5.00: status: { DRDY ERR }
Mar 25 22:29:27 RackStation kernel: [ 3019.130000] ata5.00: error: { UNC }
Mar 25 22:29:27 RackStation kernel: [ 3019.140000] ata5.00: failed command: READ FPDMA QUEUED
Mar 25 22:29:27 RackStation kernel: [ 3019.140000] ata5.00: cmd 60/00:18:00:f2:e1/01:00:04:00:00/40 tag 3 ncq 131072 in
Mar 25 22:29:27 RackStation kernel: [ 3019.140000] res 41/40:18:00:f2:e1/40:00:04:00:00/40 Emask 0x9 (media error)
Mar 25 22:29:27 RackStation kernel: [ 3019.150000] ata5.00: status: { DRDY ERR }
Mar 25 22:29:27 RackStation kernel: [ 3019.150000] ata5.00: error: { UNC }
Mar 25 22:29:27 RackStation kernel: [ 3019.150000] ata5.01: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 25 22:29:27 RackStation kernel: [ 3019.160000] ata5.02: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 25 22:29:27 RackStation kernel: [ 3019.170000] ata5.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 25 22:29:27 RackStation kernel: [ 3019.180000] ata5.04: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
Mar 25 22:29:28 RackStation kernel: [ 3020.730000] ata5.04: limiting SATA link speed to 1.5 Gbps
Mar 25 22:29:34 RackStation kernel: [ 3026.450000] ata5.00: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:34 RackStation kernel: [ 3026.450000] ata5.01: failed to read SCR 1 (Emask=0x40)
Mar 25 22:29:34 RackStation kernel: [ 3026.4Mar 26 15:04:05 RackStation kernel: [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
-
"Google zegt:" Check je SATA connectoren. Druk de disks eens goed aan.
-
Dr Google lijkt dat inderdaad te suggereren.
Vooraleer ik mijn volgende repair poging start (na de parity scan), eens alle schijven eruit halen en terug plaatsen, alsook de eSata kabel even losmaken en terug vastmaken (hoewel dat niet evident is in mijn rack).
Dank jullie voor de tips :)
-
De scans op de nieuwe HDD zijn klaar, en die is prima in orde. De pariteitscontrole op de degraded array zit nu op 28%, en zal dus nog wel effe duren.
Het enige zorgwekkende is dat ik voorlopig grote problemen heb bestanden van de NAS te lezen. Als ik FileStation gebruik, komt er meestal na een tijdje "bewerking mislukt" op te staan. Gebruik ik gewoon windows, dan blijft we "busy" balk maar lopen, op Mac krijg ik zelf een error in de log. Ik denk dat ik best gewoon geduldig wacht tot de hele scan voorbij is vooraleer de NAS nog actief te gebruiken.
Buiten de 16TB volume limiet, zijn dit toch wel de momenten dat je jezelf vervloekt om destijds niet gewoon de plus versie te kopen :P
-
Even een kleine update:
- De controle is nu afgelopen, zonder veel problemen. 2 errors op disk nummer 4, maar dat is logischerwijs de volgende die zijn geest zou moeten geven.
- Ik heb net alle schijven even verwijderd, de contacten proper gemaakt, en deze terug geplaatst.
- Vervolgens de nieuwe schijf terug geplaatst, en ben nu terug begonnen met de repair van de RAID-6 array. Wel alle services nog steeds uitgeschakeld deze keer.
- Hopelijk meer geluk deze keer ;)
-
Laatste reactie van mij (hoop ik) ;)
De repair is nu wel succesvol verlopen. Dank jullie alle drie voor de goede tips (ook al kan ik onmogelijk weten waarom het nu gewerkt heeft).
Achteraf bekeken ben ik toch zeker blij de DSM upgrade nog niet gedaan te hebben. Wie weet welke problemen had dit nog kunnen veroorzaken.
Deze ochtend vlak na de repair, even de DSM bijgewerkt, alsook alle packages. Daarna de eerste service gestart, toen moest ik naar mijn werk vertrekken.
-
"ook al kan ik onmogelijk weten waarom het nu gewerkt heeft"
Er zit tijd tussen de constatering van slechte sectoren en het repareren daarvan.
Hoe lang dat is weet ik niet maar zal verschillen tussen fabrikant/type.
Wat ik mij voor kan stellen is dat hoe groter de data dichtheid is (grotere capaciteit) hoe langer dat duurt.
De controle`s en reparaties zullen er wel voor gezorgd hebben dat de DS niet/slecht benaderbaar was...
Goed dat het weer draait.