Synology-Forum.nl
Hardware ondersteuning => NAS hardware vragen => Topic gestart door: Briolet op 14 maart 2019, 10:15:19
-
In mijn 415+ gaf mijn nieuwste drive al lang problemen. (3 jaar oud, maar de oudste in de set is 7 jaar oud) Af en toe een read error en een uitgebreide smarttest bleef altijd op 90% hangen.
Deze week ging het aantal errors plots van 10 naar boven de 70. Voor mij een reden om hem te vervangen. Ik heb de schijf via het menu in opslag beheer uit de raidset gegooid. Je moet dan het wachtwoord ingeven en ik kreeg de melding dat de systeem partities verwijderd zouden worden. Tot zover duidelijk.
Ik heb de oude schijf er vervolgens fysiek uitgehaald, de nieuwe schijf erin en alles gerepareerd. (Ca 15 uur bij de 3 TB schijf). Dit alles zonder de nas uit te schakelen.
Nu het probleem. Ik wilde de oude schijf wissen en omdat mijn 415+ nog een vrij slot heeft, wilde ik dat via de nas laten doen. Omdat hij netjes via de software uit de raidset gezet was, nam ik aan dat er geen conflicten met de bestaande set zouden optreden. Maar, zodra ik de schijf in de nas drukte, gingen alle lampjes uit, op een blauw knipperend lampje na. Bij het weer verwijderen van de schijf, startte de nas weer netjes op.
In het gewone log was geen melding van een ongecontroleerde shutdown, maar het massages.log bestand liet wel duidelijk een volledige restart van de kernal zien.
Mijn vraag is nu of ik dit had kunnen verwachten met het terug plaatsen van de oude disk? Ik had tenslotte de melding gehad dat de systeem partities verwijderd waren en vóór het verwijderen was deze schijf geen onderdeel meer van een raidset.
-
Volgens mij had dit niet mogen gebeuren.
Wat als je de NAS uitzet, die oude HD plaatst en de NAS opstart ?
-
Dit gaat fout omdat de RAID partitie op de oude schijf nog steeds de RAID kenmerken/IDs heeft van de RAID die in de NAS actief is en de RAID controller daardoor in de war raakt. Deze worden bij het verwijderen van een schijf uit RAID niet op de verwijderde schijf gewist.
Je moet nooit een RAID schijf die je verwijderd hebt uit een RAID volume terugzetten zonder hem eerst te wissen. Dat is niet alleen bij Synology zo maar bij alle RAID systemen.
@Birdy Als je jouw voorstel uitvoert is de kans zeer groot dat je complete RAID volume na de opstart om zeep is. Dat soort experimenten moet je met een RAID beslist niet doen. ;)
-
…Deze worden bij het verwijderen van een schijf uit RAID niet op de verwijderde schijf gewist.…
Dat geldt volgens mij alleen als je hem er zo uit trekt. Maar hier had ik hem via opslagbeheer uit de raidset verwijderd. Ik zag zelfs de melding voorbij komen dat de systeem partitie verwijderd werd. Ik had dan toch echt verwacht dat ook alle raid kenmerken weg zouden zijn.
Op zich had ik de schijf ook direct erna kunnen formatteren, maar het gaf en veiliger gevoel om eerst te rebuilden met de nieuwe schijf, voordat ik de oude wiste. Bovendien wilde ik zo snel mogelijk weer een gerepareerde raid hebben.
Ik begon me nu af te vragen of er een hardware probleem in de 4e bay zat. Die bay had ik tot nu toe nog nooit gebruikt. Ik zal de schijf komend weekend eens in een externe behuizing wissen en dan nog eens in de nas steken.
-
Ik denk dat de NAS even uit moet worden gezet, dan de nieuwe schijf er in, en dan weer opstarten. Ik kan dit zelf niet controlleren, dus weet niet zeker of dit werkt!
-
Het gaat niet om het plaatsen van een nieuwe schijf maar om een schijf die al eerder in dezelfde RAID is gebruikt en is vervangen.
Zoals gezegd, zo'n schijf moet je dus echt nooit weer terugplaatsen zonder hem vooraf te wissen. Ik heb dat al zo vaak mis zien gaan....
-
Ik ben het helemaal met @Hofstede eens.
En niet alleen als je zelf een raidset gemaakt hebt maar je moet niet vergeten dat de systeem partitie ook een raidset is, waar van geboot wordt.
Dat bootprocess zit ver voor het actief worden van DSM en als het bootsysteem iets ziet wat hij niet snapt is het gewoon over en uit.
-
Ik zou het een bug van Synology vinden als je hem niet opnieuw kunt terugplaatsen als hij eerst netjes verwijderd was. De schijf zou zich dan als nieuwe schijf moeten gedragen.
…Ik heb dat al zo vaak mis zien gaan....
Dat is omdat er vaak geschreven wordt dat je gewoon de oude schijf eruit kunt trekken en dan met een nieuwe schijf kunt herstellen. Veel mensen doen het dan ook op die manier. Als je dat doet, blijft alle raid info op oude schijf staan.
Als je de schijf via de software verwijderd behoort die info gewist te zijn. Bij het verwijderen via de software meldt hij zelfs dat de systeem partities gewist worden. Daarna stond hij in het rijtje disks als "niet geïnitialiseerd".
Ik heb de schijf nu in een losse behuizing gewist. (Mac geformatteerd). Als ik de schijf er nu in druk, gebeurd weer precies hetzelfde. Da nas crasht, alle lampjes uit. Nu kan het zeker niet aan achtergebleven info liggen. Misschien dat de drive gewoon even teveel stroom trekt bij het aansluiten?
Nu maar een cold-swap gedaan. Dit gaat wel goed. De nas start op en de 4e schijf staat er nu gewoon in als niet-geïnitialiseerd. Er loopt inmiddels een secure errase zodat ik hem met goed geweten kan weggooien.
-
Op deze regenachtige zaterdag, toch even getest met mijn DS411Slim (niet hotswap).
1 - SHR met 3 HD's gemaakt.
2 - Heb HD3 via het menu in opslag beheer uit de raid set verwijderd.
3 - DS uitgezet.
4 - HD3 vervangen door een andere.
5 - DS gestart.
6 - Nieuwe HD toegevoegd aan pool en herstellen, done.
7 - DS uitgezet
8 - Oude HD in slot 4 gezet
9 - DS gestart.
Resultaat:
- Start zonder problemen op.
- Kan Secure Erase starten, maar niet gedaan.
[attachimg=1]
Ik had tenslotte de melding gehad dat de systeem partities verwijderd waren en vóór het verwijderen was deze schijf geen onderdeel meer van een raidset.
Ik heb die HD even aan m'n PC gehangen en zie dat de systeem partitie niet is verwijderd:
[attachimg=2]
Sterker nog, de HD wordt nog steeds als onderdeel van de RAID-set van de DS411Slim gezien:
[attachimg=3]
Dus, waarschijnlijk, is Hot Swap dan toch niet zo handig, in dit geval.
-
Op deze regenachtige zaterdag, toch even getest …
Ik heb net 35 km op de racefiets gezeten en geen druppel regen gezien. Wel veel wind. 💨
…Ik heb die HD even aan m'n PC gehangen en zie dat de systeem partitie niet is verwijderd:
Dat is duidelijk. Maar had je wel de melding gezien bij het softwarematig verwijderen, dat de systeem partitie gewist wordt? Want die melding zag ik wel voorbij komen, en dan zou je er van uit moeten gaan dat hij ook weg is.
Maar bij mij ging een hot-swap ook mis na opnieuw formatteren. Bij mij speelde zeker ook nog iets anders.
Ik had nog nooit een hot-swap gedaan en bij bay 3 ging dat gewoon netjes zoals verwacht. Het blijft natuurlijk veiliger om hem gewoon uit te zetten bij een schijf wisseling.
-
Als je in DSM een disk uit de raidset haalt dan haalt hij enkel het data volume(s) uit de raidset maar blijft de systeem partitie gewoon bestaan.
Daarom kun je zo'n disk ook niet zomaar weer in een willekeurig ander systeem gebruiken.
Je zult eerst die systeem partitie moeten verwijderen.
En die systeem partitie zit ook in de bootsector van die disk als zijnde een Raid 1 bootdisk.
Dus hot swappen is geen probleem, maar terug zetten van een oude disk moet je niet doen zonder eerste elders die systeem partitie te verwijderen.
DSM heeft daar geen mogelijkheden voor.
Het is overigens best mogelijk dat die systeem partitie door DSM gewist is, maar wel als partitie blijft staan.
Dat zou @Birdy kunnen zien als hij die partitie inhoud kan bekijken terwijl hij extern is.
-
@Briolet
Maar had je wel de melding gezien bij het softwarematig verwijderen, dat de systeem partitie gewist wordt?
Jazeker.
dan zou je er van uit moeten gaan dat hij ook weg is.
Blijkt dus van niet.
@Ben(V)
Dus hot swappen is geen probleem, maar terug zetten van een oude disk moet je niet doen zonder eerste elders die systeem partitie te verwijderen.
Je hebt gezien dat dit bij mij geen probleem was.
Dat zou @Birdy kunnen zien als hij die partitie inhoud kan bekijken terwijl hij extern is.
Dat heb je kunnen zien in mijn test, dat ik, extern , de partitie inhoud kan zien: plaatje 3.
-
Ik ben zelf nog wat aan het proberen geweest nu die 4 disk er nog in zit.
Na een secure errase zie ik dit in /dev
brw------- 1 root root 8, 32 Mar 14 20:15 sdc
brw------- 1 root root 8, 33 Mar 14 20:15 sdc1
brw------- 1 root root 8, 34 Mar 14 20:15 sdc2
brw------- 1 root root 8, 37 Mar 14 20:15 sdc5
brw------- 1 root root 8, 48 Mar 14 20:15 sdd <---- schijf 4
brw------- 1 root root 65, 0 Mar 14 20:15 sdq
Als ik het goed heb heeft sdc1, sdc2 etc te maken met de partities op schijf 3. Bij sdd zijn er geen nummers, dus geen partities.
Als ik een nieuwe storagepool aanmaak en daar de 4e schijf aan toevoeg, wordt de schijf geïnitialiseerd. Bij /dev zie ik nu
brw------- 1 root root 8, 32 Mar 14 20:15 sdc
brw------- 1 root root 8, 33 Mar 14 20:15 sdc1
brw------- 1 root root 8, 34 Mar 14 20:15 sdc2
brw------- 1 root root 8, 37 Mar 14 20:15 sdc5
brw------- 1 root root 8, 48 Mar 16 18:10 sdd <---- schijf 4
brw------- 1 root root 8, 49 Mar 16 18:10 sdd1
brw------- 1 root root 8, 50 Mar 16 18:10 sdd2
brw------- 1 root root 8, 51 Mar 16 18:10 sdd3
brw------- 1 root root 65, 0 Mar 14 20:15 sdq
Bij schijf 4 zijn nu de partities aangemaakt. En ook als ik de storagepool verwijder, blijven ze er staan. Alleen een secure errase haalt ze weg.
-
Ik heb nog eens gedeactiveerd, nu wel goed gelezen en kom terug op:
@Briolet
Maar had je wel de melding gezien bij het softwarematig verwijderen, dat de systeem partitie gewist wordt?
Jazeker.
Ik krijg 2 schermpjes:
[attachimg=1]
[attachimg=2]
Hieruit blijkt dat de systeem partitie NIET gewist wordt maar, dat de HD uit de geassocieerde systeempartitie gezet wordt.
Dus IDD, er worden geen partities of data gewist.
En dat is dan ook de reden waarom ik deze melding krijg als ik HD4 terug zet:
[attachimg=3]
-
Dat had ik ook niet verwacht. Dat gebeurt ook niet als je in Linux zelf een schijf uit een RAID haalt en heb het ook nog nooit gezien bij welke hardware RAID controller ook.
-
…maar, dat de HD uit de geassocieerde systeempartitie gezet wordt.
Die tekst kun je dus op verschillende manieren interpreteren. Als een schijf geen onderdeel meer uitmaakt van de pool en de systeempartitie, interpreteer ik dat hij ook niet meer kan conflicteren.
Inmiddels heb ik met die schijf een 2e opslagpool aangemaakt. (Met volume en share). Vervolgens de opslagpool weer gewist. Nu staan er zeker geen conflicterende zaken meer op. Nu kon in de schijf er wel een paar maal probleemloos uit halen en weer in steken. Er is dus niets mis met de hardware.
Dan blijft alleen nog de vraag waarom ik de 2e crash kreeg nadat ik de schijf op de maf geformatteerd had naar Apple formaat. Zou daarbij toch nog een boot deel van de na achter gebleven zijn?
-
Ter info. Op 16 maart ben ik een uitgebreide smart test gestart op de defecte schijf. Vanaf het begin bleef de test op 90% hangen bij deze schijf en heb de test steeds binnen een week afgebroken.
Dit keer zat hij toch in een ongebruikte bay en heb de test maar laten lopen. Gisteren was hij klaar. Dat is na 13 dagen! Wel met het resultaat wat ik verwacht had: Mislukt.
Nu staat dit resultaat in het logboek van de schijf zelf en ziet dsm hem als een defecte schijf en niet langer als een onbetrouwbare schijf met veel fouten. Voor de test kon je de waarschuwing nog uit zetten en er een volume op maken. Nu helemaal niet meer. Einde testen dus. ;)
-
Ik heb de defecte disk nog in de nas zitten en kreeg vannacht om 1 uur en 6 uur een mailtje van de nas:
Schijf 4 op DS415+ is beschadigd en begint te falen. Maak onmiddellijk een back-up van uw gegevens en vervang vervolgens de schijf.
Schijfinformatie:
Merk: WDC
Model: WD30EFRX-68EUZN0
Capaciteit: 2.7 TB
Serienummer: WD-WCC4N1TD16UR
Firmware: 82.00A82
S.M.A.R.T.-status: Mislukt
Volgens mij is DSM de draad kwijt. Deze disk is niet geïnitialiseerd. Er staat geen dsm op, dus dsm moet kunnen weten dat deze schijf geen data bevat. In elk geval niet in een vorm dat dsm er iets mee kan doen. Blijkbaar mist er een check in hun waarschuwingsalgoritme. ;)