Synology-Forum.nl
Hardware ondersteuning => NAS hardware vragen => Topic gestart door: Martijndez op 24 september 2014, 22:27:46
-
Het is de goden verzoeken, vandaag een DS115j gekocht als ofsite backup en ja hoor ik heb problemen met mijn DS415play. Deze heeft 3 x 6tb RED schijven in SHR. Ik krijg de melding dat het bad sectors zijn op het systeem volume van disk 1. Het vreemde is dat smart geen rare uitslag geeft (volgens mij). DSM geeft ook aan dat de schijintegriteit gezond is. Voor de zekerheid nu een lange smart-test aan het runnen
Paar bijzonderheden;
1. In de afgelopen 4 weken van 1, naar 2, naar 3 x 6tb schijven gegaan. Allemaal van een verschillende levarancier en productie datum. Met de uitbreiding van 2 x6tb naar 3 x6tb SHR was hij afgelopen weekend klaar na 6 dgn uitbreiden
2. DSM 5.1 staat geinstalleerd. Ik wilde downgraden door het version bestandje aan te passen wat werkte bij voorgaande versies. Nu dus niet en ik moest via de web assistent DSM5.1 weer installeren, lagere versie pakte deze niet.
Iemand een idee of zal ik DISK 1 maar RMA sturen? Zou dit eventueel aan de beta versie kunnen liggen gezien hij alleen rept over de systeempartitie?
-
Nou ja, niet dat ik je echt kan helpen, maar wat je noemt bij punten 1 en 2 komt het bij mij over als juist de goden willen verzoeken. De 415 play moet ook pas net nieuw zijn. Waarom je dan in etappes in een kort tijdsbestek daar schijven in gaat plaatsen van verschillende leveranciers en niet direct meteen je 415play in de geplande setting installeert met drie gelijksoortige schijven (waarom niet meteen 4 ?), vind ik onbegrijpelijk.
-
Punt 1 is gewoon een eigenschap van SHR. Ik begrijp dat het uitbreiden van volume heel wat vraagt aan een HDD. Maar een schijf met net aan 900 draai uren zou dit toch moeten kunnen. Het plaatsen van schijven van verschillende leverarancies (=dus verschillende batches) word juist aangeraden om een soort van wet van murphy te verkomen, immers hebben alle harde schijven ongeveer een vergelijkbare levensduur.
Wat betreft punt 2 is het natuurlijk wat geklungel en in het verleden behaalde resultaten bieden natuurlijk geen garanties voor de toekomst. Maar om wijzer te worden moet je nu eenmaal leren van gemaakte fouten.
-
Sorry, met verschillende leveranciers dacht ik te begrijpen dat je mogelijk schijven van verschillende merken hebt gebruikt, maar het gaat alleen om spreiding van je producten uit een verschillende productiebatch. Maar dan nog vind ik die etappes bij punt 1 vragen om problemen. Begin eens helemaal met een schone lei, vers DSM installeren, formatteren indelen etc., alles volgens het boekje en kijk dan eens wat het oplevert.
-
Bedankt voor het meedenken maar dit is voor mih geen pasende oplossing omdat dit zou betekenen dat ik 5tb aan data kwijt raak.
Wellicht moet ik mijn vraag concretiseren. Waarom greeft DSM enerzijds aan dat ik Volume problemen heb door schijf1 maar anderzijds aangeeft dat de schijfintegriteit in orde is een ook geen vreemde waardes aangift in de smart?
-
dit is voor mih geen pasende oplossing omdat dit zou betekenen dat ik 5tb aan data kwijt raak.
En die nieuwe DS115j die je vandaag hebt gekocht? Hoe groot is de capaciteit van die ene schijf die erin is gezet?
Mocht dat ook een 6 TB schijf zijn, kun je die 5 TB daar op parkeren, totdat je DS 415 Play op orde is.
-
Zou volume1 gewoon laten repareren, ik zie geen probleem op schijf 1 (S.M.A.R.T.) alhoewel, ik zie niet ALLE ID's in smartinfo.jpg dus, je moet even naar beneden scrollen.
-
DSM maakt als hij geinstaleerd wordt standaard twee partities aan op elke disk.
Te weten een systeem partitie aan het begin van de schijf en een swap partitie aan het eind van de schijf.
Alle systeem partities van alle disken worden in een raid 0 set opgenomen. Idem met de swappartities.
Op die systeempartities wordt DSM geinstalleerd.
Wat jouw systeem nu zegt is dat de systeempartitie van disk 1 niet meer overeenkomt met de andere systeempartities.
Dat je smart info geen fout geeft zegt niet alles, die constateerd alleen iets als er schrijfactie niet goed gaat.
Uiteraard is een backup maken nu je eerste prioriteit.
Ik neem aan dat je geen optie gekregen hebt om die systeempartitie repareren?
Zo niet dan zou je die disk eruit kunnen halen en aan een pc hangen en die partities verwijderen. Je kunt dan meteen even de diagnose software van WD er op los te laten.
Daarna stop je hem terug en neemt hem weer op in je SHR. DSM zal dan ook de systeempartitie er weer op zetten.
-
Als het het systempartition betreft, zou je ook kunnen proberen om vanuit de Command line:
echo repair > /sys/block/md0/md/sync_action
uit te voeren.
Deze zou dan de raid 1 set van je systempartie moeten controleren en repareren.
Eventuel herhalen voor md1
(md2 zou je feitelijke partitie moeten zijn met je data)
Zie ook:
Volgens opgave van de help van synology dient dit op regelmatige basis gedaan te worden.
Feitelijk is dit het controleren of alle data van je SHR (comprised of three or more disks), RAID 5, or RAID 6 nog correct is.
Er is binnen de GUI geen mogelijkheid om dit te schedulen (bij mijn weten).
Er is uitsluitende de mogelijkheid om dit te starten vanuit Storage manager/Volume
Ik kwam toevallig een discussie hierover tegen op het engelstalige forum.
http://forum.synology.com/enu/viewtopic.php?f=19&t=65340&start=30 (http://forum.synology.com/enu/viewtopic.php?f=19&t=65340&start=30)
Vanuit de CLI (command line) kun je Data scrubbing starten door middel van:
echo repair > /sys/block/md2/md/sync_action
Dit is hetzelfde als wat je start vanuit de GUI
Er is ook nog een andere mogelijkheid nl:
echo check > /sys/block/md2/md/sync_action
Beide opties zijn wel te schedulen.
Een leuke is ook:cat /proc/mdstat
Deze geeft aan de voortgang van het proces, in mijn geval:
md2 : active raid5 sda5[0] sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[=>...................] check = 5.0% (148345984/2925531648) finish=1464.8min speed=31597K/sec
(bij mij duurt deze check nog wel een paar uurtjes dus.)
-
Volgens mij kun je die repair ook starten vanuit DSM met behulp van de Beheer functie in Opslag beheer.
-
DSM geeft daar alleen de optie "Start data scrubbing".
Geen idee of hij dan ook de systeem partitie doet, maar hij is wel heel lang bezig omdat de data partities in ieder geval gedaan worden.
Een aparte optie voor alleen de systeem partitie is er niet dus even optie van hansiedown volgen lijkt me eenvoudiger.
-
Na een reboot kon ik onder beheer de schijf laten controleren. Deze staat nu al 15u lang de pariteits consitie controle aan het doen en is nu op ongeveer een kwart. Dit is ook echt alleen een controle denk ik en er wor dnog niet iets daadwerkelijks gerepareerd?
-
Dat klopt. Maar die actie controleert alleen je data partitie en niet de systeempartitie en zal die dus niet herstellen.
-
Dit is ook echt alleen een controle denk ik en er wor dnog niet iets daadwerkelijks gerepareerd?
Nee als er een fout gevonden wordt zal DSM proberen die data op een andere sector weg te schrijven.
Dus het wordt wel gerepareerd.
Ik betwijfel echter of ook de sytseem partitie gedaan wordt.
-
BEdankt voor het antwoord. Als de systeem partitie niet word gecontroleerd zou dit toch een manco zijn in DSM immers heeft DSM zelf ontdekt dat er problemen zijn met de systeempartitie?
-
Nu krijg ik weer een meding in DMS dat er een bad sector in disk 3 is geremapped.
Weer het vreemde, in de integriteitsinfo van schijf 3 en in de smartinfo kan ik de waarde over de bad sector niet terug vinden. Even voor mijn duidelijkheid Bad sectore remaped zo toch een waarde moeten geven bij Relocated_Sector_Ct in de smart info?
Disk 1 is de schijf die momenteel ook al gecontroleerd word. Disk 1 heeft 900 draaiuren en disk 3 230 uren, beide WD 6tb Reds, beide van verschillende batches en productie data. Ik vind het wel een beetje erg toevallig. Zou dit niet aan DSM5.1 beta kunnen liggen?
-
Je moet even begrijpen dat er twee zaken spelen hier. De s.m.a.r.t. test en info komt van de controller die in de harddisk zelf zit. Jouw foutmeldingen komen van DSM. Die twee weten niets van elkaar.
Zoals ik al schreef kan de diskcontroller alleen iets realloceren als er een schrijffout ontdekt wordt door de diskcontroller.
Wat DSM ondekt heeft is een lees fout. Hij ziet op een disk dat er iets anders staat dan op de andere disken samen. DSM zal dan die sector die hij als fout gelezen heeft niet meer gebruiken en de data op een andere sector wegschrijven. Die sector wordt door DSM nooit meer gebruikt en zal de diskcontroller hem dus ook nooit reloceren.
Op zich is het feit dat DSM een fout ontdekt en een andere sector gaat gebruiken niet heel verontrustend, wat wel verontrustend is dat het op meerdere schijven gebeurd. Als het maar niet blijft gebeuren.
SHR beschermd je maar tegen het uitvallen van een disk, niet als er twee gelijktijdig gaan.
Als je twijfelt over je disken zou ik er een uitbouwen en aan je PC hangen en de software van WD erop loslaten. Die doet een lowlevel controle.
-
Ok, ik denk dat ik het nu begrijp. Wijzen de foutmelding van DSM altijd op een hardware probleem? Of kan de leesfout ook iets software matig zijn?
Ik vind het erg vreemd dat twee nieuwe RED schijfen á 250€ per stuk nu al foutmeldingen geven. Er is nu nog steeds een pariteitsconsistentie gaande op schijf 1. Als die klaar is ga ik de schijven wel controleren via WD software op mijn PC. Theoretisch zou deze lowlevel software niets moeten doen met de data die er op staat lijkt mij?
Ik zie dat synocommunity ook een lowlevel disk utitly packages hebben (in de beta) welke "ef2fsprogs" bevat en "screen". ZOu dit ook kunnen werken?
-
Ik vind het erg vreemd dat twee nieuwe RED schijfen á 250€ per stuk nu al foutmeldingen geven.
Op het forum toch "regelmatig" gezien dat nieuwe schijven toch al defect bleken te zijn.
De prijs doet daar niet aan af, helaas.
-
Het punt is als je met de software van WD test en die geeft iets fouts aan, dan heb je een grond voor een garantie claim.
Is dacht dat de WD software twee soorten test heeft. Waarvan er een niet destructief.
Ik weet het niet helemaal zeker meer maar het zal je beslist vertelt worden voor dat hij z'n gang gaat.
Ok, ik denk dat ik het nu begrijp. Wijzen de foutmelding van DSM altijd op een hardware probleem? Of kan de leesfout ook iets software matig zijn?
Theoretisch kan er ook softwarematig iets fout gaan, maar dan moet er iets zijn dat de data op de schijven verandert buiten het filesystem om. Dat lijkt onwaarschijnlijk, alhoewel virussen ed dat nog wel eens doen.
Wat betreft jou vraag over DSM5.1, nee dat is onwaarschijnlijk. Het filesystem en ook het raid systeem (inclusief SHR) is volledig Linux en is niet door Synology gemaakt. DSM is een laag boven op Linux.
-
Het filesystem en ook het raid systeem (inclusief SHR) is volledig Linux en is niet door Synology gemaakt. DSM is een laag boven op Linux.
Synology Hybrid RAID (SHR) is een geautomatiseerd RAID-beheersysteem van Synology dat speciaal is ontworpen om tegemoet te komen aan de behoefte van een eenvoudige te installeren opslagmedium.
-
Sterker nog, voor degene die het nog niet opvalt, SHR is de afkorting van Synology Hybrid RAID :D
https://www.synology.com/nl-nl/knowledgebase/tutorials/492
-
Klopt maar het is onder water gewoon "linux software raid" waar Synology een beheerschil overheen gelegd heeft.
En die beheer schil doet niets aan lezen of schrijven van de data. Kortom het is gewoon linux.
-
Natuurlijk is de basis (onderwater) Linux maar ik herhaal toch:
Synology Hybrid RAID (SHR) is een geautomatiseerd RAID-beheersysteem van Synology dat speciaal is ontworpen om tegemoet te komen aan de behoefte van een eenvoudige te installeren opslagmedium.
"Speciaal ontworpen", houdt volgens mij in dat Synology dat deel (SHR) software (dus niet maar een schil) zelf heeft geschreven heeft geschreven, maar goed, is verder niet zo relevant ;)
-
"Speciaal ontworpen", houdt volgens mij in dat Synology dat deel (SHR) software (dus niet maar een schil) zelf heeft geschreven heeft geschreven, maar goed, is verder niet zo relevant ;)
Als ik kijk in bij cat /proc/mdstat dan zegt deze wel dat het een actieve RAID5 betreft. Ook in processen zie ik MD2_RAID5 proces draaien. Dus volgens linux is het dus daadwerkelijk een RAID5 en geen SHR? Of is dit erg kort door de bocht geredeneerd?
md2 : active raid5 sda5[3] sdb5[0] sdc5[2]
11711575296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [U_U]
[==================>..] recovery = 91.3% (5347113704/5855787648) finish=397.6min speed=21321K/sec
Nog een vraag, ik probeer het te begrijpen. Is data scrubbing hetzelfde als pariteits consistentie controle? Ik weet dat het beide bedoelt is om beschadigde sectoren te vinden maar is het ook hetzelfde techniek?
-
Ja. Zijn parity check en data scrubbing zijn twee termen voor hetzelfde.
En dat je RAID5 ziet klopt. SHR is alleen een extra, door Synology ontworpen, layer tussen gebruiker en Linux bestandssysteem die het voor de gebruiker makkelijker maakt om de datavolumes te beheren en aan te passen.
-
Als ik kijk in bij cat /proc/mdstat dan zegt deze wel dat het een actieve RAID5 betreft. Ook in processen zie ik MD2_RAID5 proces draaien. Dus volgens linux is het dus daadwerkelijk een RAID5 en geen SHR? Of is dit erg kort door de bocht geredeneerd?
Zoal ik al zei is SHR niets meer dan een beheer schil over Linux software raid heen. Wat de marketing van Synology ook zegt.
Als je bijvoorbeeld vier gelijk disken SHR maakt zal er onder water raid5 gebruikt worden.
Als er twee disken van 1TB en twee van 2TB in SHR gezet worden krijg je onder water een raidset van 4x1TB in raid 5 en 2x 1TB in raid 1.
Verder heeft DSM nog diskgroepen en die realiseren ze met standaard Linux LVM(Logical Volume Manager)
-
En dat je RAID5 ziet klopt.
Klopt idd, heb ik ook wel eens in andere topics laten zien.
SHR is alleen een extra, door Synology ontworpen, layer tussen gebruiker en Linux bestandssysteem die het voor de gebruiker makkelijker maakt om de datavolumes te beheren en aan te passen.
Buiten dat natuurlijk, SHR t.o.v. de klassieke RAID heeft nog een groot voordeel wanneer je met verschillende HD groottes werkt, zie "Hoe maximaliseert SHR opslag?" (https://www.synology.com/nl-nl/knowledgebase/tutorials/492)
-
Helemaal correct Birdy.
SHR maakt het makkelijk voor je en zoekt de verschillende combinaties van raid5 en raid1 zelf voor je uit.
Je kunt dat echter op linux niveau ook zelf regelen.
Moet je wel verstand van hebben en is dus lang niet zo makkelijk als DSM.
-
Korte terugkoppeling. Vandaag was DSM klaar met datascrubbing van de shr partitie, kreeg de melding in DSM dat de volume gemaakt was. Hierna direct weer een melding in DSM dat er fouten zijn in de systeem partitie. In putty de opdracht gegeven voor data scrubbing op de Systeem partitie en de swap. Na een restart geen melding meer in DMS. Duimen dat het zo blijft.
-
Pffffff 8)
-
Blij dag het weer goed werkt.
Toch slordig dat Synology z'n system partitie niet scrubed.
-
Enhancement request ?
https://www.synology.com/nl-nl/company/inquiry_form/feedback
-
Goed idee. Ga er meteen een invullen.
-
Vannacht weer een melding dat disk 2(!) beschadigde sectoren op de systeempartitie heeft. Ik moet weer een scrubbing uitvoeren waarbij de scrubbing standaard in dsm uberhaubt niet de datapartitie onder handen neemt :-s.
Eerst dus disk 1, toen 3 en nu 2. Volgens mij zijn er nu twee opties. Of er is toch een software fout in dsm5.1 of de 6tb RED schijven zijn niet goed/hebben kinderziektes. Ik ga vandaag de schijven testen met de WD software op mijn windows PC om dit laatste uit te sluiten.
-
Door drukte op werk lag het even op z'n gat maar vandaag was eindelijk schijf 3 klaar met de uitgebreide controle van WD eigen diangostische tool. Alle drie de schijven geven aan dat ze 0 errors hebben. Vandaag voor het eerst mijn server in 3 dagen aan gedaan en ik rkijg gelijk een melding in DSM dat het systeem is vastgelopen en ik opnieuw moet opstarten voor een systeem controle. Bij opnieuw opstarten gebeurt er geen systeem controle en kom ik direct weer in DSM. Het gekke is ook dat DS niet te zien is in synology assistant maar wel beikbaar is. Morgen maar een uitgebreide ticket aanmaken ...... :S
-
Klopt het dat deze volgende errors inderdaad mijn externe hdd betreft?
Sep 27 10:41:13 DS415play kernel: [216914.226399] EXT4-fs error (device sdq1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Sep 27 10:41:13 DS415play kernel: [216914.237774] EXT4-fs error (device sdq1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Sep 27 10:41:13 DS415play kernel: [216914.252355] EXT4-fs error (device sdq1) in ext4_new_inode:1161: IO failure
Sep 27 10:41:15 DS415play kernel: [216915.698002] EXT4-fs error (device sdq1): ext4_put_super:864: Couldn't clean up the journal
Sep 27 10:41:15 DS415play kernel: [216915.706586] EXT4-fs (sdq1): Remounting filesystem read-only
Sep 27 18:25:27 DS415play kernel: [13684.428084] EXT4-fs error (device sdq1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Sep 27 18:25:27 DS415play kernel: [13684.439414] EXT4-fs error (device sdq1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Sep 27 18:25:27 DS415play kernel: [13684.453960] EXT4-fs error (device sdq1) in ext4_new_inode:1161: IO failure
Sep 27 18:25:29 DS415play kernel: [13686.624525] EXT4-fs error (device sdq1): ext4_put_super:864: Couldn't clean up the journal
Sep 27 18:25:29 DS415play kernel: [13686.632998] EXT4-fs (sdq1): Remounting filesystem read-only
Sep 27 18:49:25 DS415play kernel: [15120.451881] EXT4-fs error (device sdr1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Sep 27 18:49:25 DS415play kernel: [15120.463098] EXT4-fs error (device sdr1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Sep 27 18:49:25 DS415play kernel: [15120.477673] EXT4-fs error (device sdr1) in ext4_new_inode:1161: IO failure
Sep 27 18:49:27 DS415play kernel: [15122.131068] EXT4-fs error (device sdr1): ext4_put_super:864: Couldn't clean up the journal
Sep 27 18:49:27 DS415play kernel: [15122.140173] EXT4-fs (sdr1): Remounting filesystem read-only
Sep 27 18:50:42 DS415play kernel: [15197.466267] EXT4-fs error (device sdq1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Sep 27 18:50:42 DS415play kernel: [15197.477940] EXT4-fs error (device sdq1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Sep 27 18:50:42 DS415play kernel: [15197.492688] EXT4-fs error (device sdq1) in ext4_new_inode:1161: IO failure
Sep 27 18:50:44 DS415play kernel: [15199.023606] EXT4-fs error (device sdq1): ext4_put_super:864: Couldn't clean up the journal
Sep 27 18:50:44 DS415play kernel: [15199.032007] EXT4-fs (sdq1): Remounting filesystem read-only
Sep 29 06:23:48 DS415play kernel: [58424.821387] EXT4-fs error (device sdq1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Sep 29 06:23:48 DS415play kernel: [58424.832687] EXT4-fs error (device sdq1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Sep 29 06:23:48 DS415play kernel: [58424.847246] EXT4-fs error (device sdq1) in ext4_new_inode:1161: IO failure
Sep 29 06:23:50 DS415play kernel: [58427.223018] EXT4-fs error (device sdq1): ext4_put_super:864: Couldn't clean up the journal
Sep 29 06:23:50 DS415play kernel: [58427.231266] EXT4-fs (sdq1): Remounting filesystem read-only
Oct 5 07:28:55 DS415play kernel: [63489.292611] EXT4-fs error (device sdq1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Oct 5 07:28:55 DS415play kernel: [63489.304114] EXT4-fs error (device sdq1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Oct 5 07:28:55 DS415play kernel: [63489.318620] EXT4-fs error (device sdq1) in ext4_new_inode:1161: IO failure
Oct 5 07:28:57 DS415play kernel: [63491.245560] EXT4-fs error (device sdq1): ext4_put_super:864: Couldn't clean up the journal
Oct 5 07:28:57 DS415play kernel: [63491.253827] EXT4-fs (sdq1): Remounting filesystem read-only
Oct 5 18:35:21 DS415play kernel: [103414.566644] EXT4-fs error (device sdr1): ext4_find_entry:1078: inode #2: comm BackupShareDele: reading directory lblock 0
Oct 5 18:35:21 DS415play kernel: [103414.578096] EXT4-fs error (device sdr1): ext4_read_inode_bitmap:164: comm BackupShareDele: Cannot read inode bitmap - block_group = 3440, inode_bitmap = 112721936
Oct 5 18:35:21 DS415play kernel: [103414.592756] EXT4-fs error (device sdr1) in ext4_new_inode:1161: IO failure
Oct 5 18:35:23 DS415play kernel: [103416.255390] EXT4-fs error (device sdr1): ext4_put_super:864: Couldn't clean up the journal
Oct 5 18:35:23 DS415play kernel: [103416.263831] EXT4-fs (sdr1): Remounting filesystem read-only
-
De afgelopen dagen is synology bezig geweest met mijn probleem. In eerste instantie was volgens hen het probleem te wijten aan mijn externe hdd, hoe dit zo'n invloed zou hebben op volume1 kreeg ik geen antwoord op. Maar ook na het unpluggen kreeg ik weer rare meldingen. Hierna op aanraden van synology een hard reset uitgevoerd en geen 3rd party packages geinstalleerd. Ook hierna weer dezelfde problemen. Nu is het blijkbaar opgechaald naar het developersteam in afwachting van hun analyse.
-
Bedankt voor je update, ben benieuwd naar hun analyse en oplossing 8)
-
Ik hoop vooral op een oplossing. Ik krijg nu zelfs meldingen dat mijn schijven uitgeplugged en ingeplugged worden.
-
In taiwan hebben ze getracht de foutmelding te reproduceren op een eigen opstelling. Dit is niet gelukt. Vandaag hebben ze de kernel op mijn DS vervangen waardoor er een speciale debugging mogelijk word. Ben benieuwd of het wat gaat opleveren. Kijk het nog even aan anders ga ik de leverancier toch maar contacten.
-
In de email conversatie liet Synology trouwens steeds de optie open dat het mogelijk toch aan de HDD lag maar in de laatste email spreken ze over "false alerts". Ook zou er iets gevonden zijn in de source code.
-
Ben nu toch wel heel benieuwd of de oorzaak boven water komt.
-
Me to, blijf dit stil volgen.
-
Vergeten een update te geven maar synology heeft enige tijd geleden de kernel weer vervangen en nu is het opgelost. Het probleem zat dus in de kernel icm de 6tb schijven
-
Bedankt voor je update, 6TB was dus even teveel voor DSM ;D
-
Ben benieuwd of er dan snel een update voor DSM 5.1 komt want 6TB schijven worden snel populair.
-
Ik vraag me af of dit wel erge prioriteit heeft voor Synology. Ik moet zeggen dat de support deze keer toch erg tegenviel. Heeft nu bijna 7 weken geduurt voordat er een oplossing kwam. Lange responstijden (soms zelfs een week), informatie door mij gegeven niet goed lezen dus daardoor zaken dubbel vragen. Na de beta sluiting zelfs mijn support ticket vergegeten zonder oplossing. Niet reageren op de simpele zoals de vraag of ik van beta naar de final moest updaten. Zeer slecht engels, hierdoor onduidelijkheid van mij en niet reageren op verduidelijkingsvragen. Maar goed het is nu gelukkig opgelost.
-
Als ik de releasenote bekijk hebben ze het inderdaad geimplenteerd in de nieuwe update:
Fixed an issue where false warning could display in System Health on Play-series. [\quote]