Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: Briolet op 03 februari 2016, 13:03:20
-
Een van mijn schijven geeft al een paar maand aan dat er 1 current_pending_sector is.
Current Pending Sector Count S.M.A.R.T. parameter is a critical parameter and indicates the current count of unstable sectors (waiting for remapping). The raw value of this attribute indicates the total number of sectors waiting for remapping. Later, when some of these sectors are read successfully, the value is decreased. If errors still occur when reading some sector, the hard drive will try to restore the data, transfer it to the reserved disk area (spare area) and mark this sector as remapped.
Omdat ze in een RAID staan zou je in eerste instantie verwachten dat hij niet eens de moeite doet deze sector te lezen, maar hem direct van de andere schijf haalt. Dit zal wel niet gaan omdat de nas geen hardware raid, maar een software raid gebruikt. Op schijfniveau, weet de HD waarschijnlijk niet eens dat hij onderdeel van een RAID is.
Toen ik deze error de eerste keer zag, heb ik een pariteitscontrole gedaan (SHR met 3 schijven). Ik dacht dat als de controle die fout tegenkwam, hij die sector vanzelf wel zou 're-alloceren'. Maar nee. Inmiddels ben ik een paar maand en meerdere pariteitscontroles verder.
Blijkbaar maakt die sector geen onderdeel uit van mijn data. Maar als hier geen data op stond, waarom heeft de HD de sector niet direct ge-realloceerd?
-
Wat laten de ID's 196 en 198 zien ?
-
Ik denk dat je op de bewuste schijf een extended SMART test moet laten lopen om dit te laten corrigeren.
-
Inderdaad :)
-
Birdy: die staan beide op nul. Evenals nr 5 (reallocated_sector_Ct)
Hofstede: Daar dacht ik ook aan na de posting. Dat duurt echter nog een paar uur. Staat inmiddels op 40%.
Ik had ergens verwacht dat dit vanzelf een keer ge-realoceerd zou worden binnen die paar maand. ;)
-
De extended SMART test bleef gisteren wel héél lang op 90% staan. Nu zie ik dat deze test ook niet de re-allocation getriggerd heeft.
Niets ernstigs voor mij, maar het woord 'pending' stoort gewoon. Het geeft aan dat er nu nog niet af is. ;)
-
Even een update. Die current_pending_sector stond bijna een jaar op 1. Hij verdween niet, ook niet na het maandelijkse datascrubbing.
Deze week viel me plots op dat de teller nu weer terug op 0 staat. Vreemd is dat de 'Reallocated_Sector_Ct" ook nog op 0 staat. Ik zou toch verwachten dat deze sector na reallocatie ergens anders in de smartinfo terug te vinden zou zijn.
De schijf is overigens okay met 30 000 bedrijfsuren en slechts 21 read errors.
Bij weergave van het aantal beschadigde sectoren, zie ik ook dat hij een jaar op 1 staat en in januari plots op nul. (Bij de weergave per maand staat er in januari -1).
[attachimg=1]
Ik houd wel van harddisks die uit zichzelf weer genezen. :D
-
Even iets achtergrond info.
Als een drive iets probeert weg te schrijven en dat lukt niet dan zal de data ergens anders weg geschreven worden en wordt de "current_pending_sector" opgehoogd.
Daarna probeert de disk de sector te realloceren en als dat lukt zal de "reallocated sector count" opgehoogd worden en de "current_pending_sector" count teruggezet.
Lukt dat niet omdat de disk bijvoorbeeld de rest van de data daar niet kan lezen dan zal de "current_pending_sector" count blijven staan.
Die gaat pas weer weg als je op die sector iets probeert weg te schijven en de disk dan concludeert dat de data die hij niet kon lezen, niet meer van belang was en dus wordt die sector afgeschreven.
Met veel statische data die een NAS nu meestal bevat blijft zo'n count vaak heel lang staan.
Het kan ook zijn dat daar alleen data staat die een van de andere software lage (bijvoorbeeld het EXT4 filesysteem) ergens dubbel opslaat en dus de data altijd kan recoveren en dan merkt bijvoorbeeld de RAID software daar niets van.
Het zijn nu eenmaal lagen op lagen van bescherming van data.
-
Een en ander zal ook te maken hebben met het verschil tussen software-raid en hardware-raid. Bij raid zou je verwachten dat hij die data van een current_pending_sector direct van de andere disk zou afhalen. Maar dat zal waarschijnlijk alleen bij een hardware raid gebeuren.
Ik ga ervan uit dat de software raid van de nas, deze data wel van de andere disk afgehaald heeft, maar dat de disk op hardware niveau niet weet dat de data op die sector onbelangrijk geworden is.
Intrigerend is echter dat de "reallocated sector count" juist niet opgehoogd is.
-
Toen ik deze error de eerste keer zag, heb ik een pariteitscontrole gedaan (SHR met 3 schijven). Ik dacht dat als de controle die fout tegenkwam, hij die sector vanzelf wel zou 're-alloceren'. Maar nee. Inmiddels ben ik een paar maand en meerdere pariteitscontroles verder.
Blijkbaar maakt die sector geen onderdeel uit van mijn data. Maar als hier geen data op stond, waarom heeft de HD de sector niet direct ge-realloceerd?
Vauit de GUI wordt er uitsluitend een datascrubbing/pariteitscontrole uitgevoerd op je data (Volume's, MD2) niet op het gedeelte waar DSM (MD0) of je SWAP (MD1) staan.
Om toch een datascrubbing/pariteitscontrole uit te voeren op MD0 en MD1, kun je de volgende commando's gebruiken:
/bin/echo check > /sys/block/md0/md/sync_action
/bin/echo check > /sys/block/md1/md/sync_action
-
Gelukkig staat in mijn taakplanner het maandelijkse script:
/bin/echo check > /sys/block/md0/md/sync_action
/bin/echo check > /sys/block/md1/md/sync_action
/bin/echo check > /sys/block/md2/md/sync_action
Dus dat gebeurde al een jaar bij mij. :P