CrystalDiskInfo visar caution hur illa är det?

Om Current Pending Sector Count är större än 0 och inte går ner till 0 efter ett tag, då har disken fått slut på reservsektorer för reallokering.
Det är illa. Gör backup snarast, helst igår, och var beredd på att disken kommer att krångla inom en snar framtid.

Inte riktigt så, visar bara att den finns veka men fortfarande läsbara sektorer vid läsning och de försvinner inte förrän sagda sektorer skrivs över med ny data då de antingen blir godkända igen eller blir reallokerade sektorer - det kan alltså ta lång tid om veka sektorn (mycket felrättning behövs vid läsning som indikation att den är vek) tex. tillhör systemfiler för windows och i princip inte skrivs om förrän du blåser disken och en ny windowsinstallation görs från början med partitionering och allt som exempel, men på datadel kan försvinna fortare. Det tråkiga är att det i SMART inte går att få reda på exakt vilken LBA-nummer som är vek och behöver skrivas om.

Ett alternativ för att fräscha upp disken är att göra en RAW disk-image och sedan skriva tillbaka diskimagen då det skriver om alla sektorer på disken och i samband med det verifieras. Ett alternativ är tex diskfresh http://www.puransoftware.com/DiskFresh.html som ibland refereras i inlägg (ej testat själv, alltså på egen risk) och som går på lågnivå i windows och läser in sektorer och skriver tillbaka samma data igen och den vägen tvingar hårddisken att förnya skrivningen och kontrollera skrivningen för sagda sektorer

Det behövs rätt många reallokerade sektorer innan man riskerar att de tar slut och då pratar vi om tre och fyrsiffriga antal när det gäller reallokerade sektorer innan man börja närma sig gränsen för reallokering i en region av diskytan och med hög antal sektor-reallokeringar visar att disken är problematisk sedan länge.

Det man skall hålla reda på är post "05 Reallocated sector count" i SMART - det är den som ger bäst indikation på om det är framtida problem med disken, C5 kan man ta lättare på och om post C3, C6 eller BB (olika beroende på snurrdisk/SSD) fortfarande är noll har man inte förlorat någon data (IO-error) vid läsning. Det man skall titta på är inte om siffran är just 0 eller 1 - utan hur fort det räknar upp - någon enstaka per år så finns det ingen orsak att stressa, men ökar det på månadsbasis så skall man hålla sina backupper uppdaterade och planera för en framtida byte då uppräkningen brukar gå allt fortare med tiden

Veka sektorer (post C5) kan man få av flera orsaker som stöt/spark eller vibrationer (av tex. granndiskars rotationsvibrationer och sökrörelsevibrationer i en NAS/server) under skrivning och upptäcks inte förrän senare när samma sektorer läses igen och spåret vinglade lite i sidled och lästa signalstyrka blev lägre och BER (Bit Error Ratio) åkte upp under läsningen just där och mer av sektorns paritetsdata (ECC) fick användas för korrektion.

Hade det varit SAS-diskar så hade den veka sektorn skrivits om automagiskt men den finessen är nogsamt borttagen för SATA snurrdiskar för att inte vara lika bra som SAS-diskar och peta ned det till 'konsumentklass' - på SSD var man dock tvungen att införa det när TLC-minnescellerna började visa tecken på mycket spänningsglidning på allt för kort tid, men fungerar bara om disken är strömsatt - ej offline-lagring utan ström.

Att det inte upptäcks redan vid skrivning beror på att läshuvudet som verifierar datat ligger enstaka 100 nanometer efter skrivhuvudet och märker inte huvudet stöts lite åt sidan under skrivningen av tex mekanisk stöt då det ändå ligger mitt i spåret efter skrivhuvudet. Ett skrivspår på disken är idag under 100 nanometer brett så det ställer enorma krav på servosystemet för läshuvudet att hålla det rätt i spåret och bättre nas och serverdiskar adapterar sig efter granndiskars rotationsvibrationer som hörs över, men hur bra algoritmerna än är så kan de inte förutse är plötsliga mekaniska stötar och där kan också läshuvudrörelser räknas in.

Med andra ord att "C5 Current Pending Sector Count" ökar behöver inte alls betyda att disken blivit gammal och nära haveri utan kan bero på att du körde i knät i datorn/bordsben eller bankade hårt i bordet under tex. spel så att vibrationerna och skakningar spreds in till disken just under skrivningen. Och försvinner den igen när sektorn ifråga skrivs med ny data utan att post '05' räknar upp så var det bara ett 'mjukt' problem och inte skada på diskytan

En snurrdisk liksom SSD har massor av fel redan vid tillverkningen men är bortmappade reda default i dess certifierings-körning på fabrik (finns i P-list om man pratar SCSI/SAS-språk men i SATA är denna oftast dold och behöver fabriks-mjukvaror för att komma åt denna) och på mång-Terabyte-disk så handlar det om hundratusentals sektorer som är bortmappade och det förvånar mig inte att man kanske missat en av dem i gränslägesfall och det sedan blivit synlig på brukarsidan senare.

Det som räknas upp i post 05 i SMART är de sektorer som mappas om efter certifiering och denna lista kallas G-list (Growing list) på SAS/SCSI-språk och samma där är dold i SATA så att man inte kan se vilken LBA den hade tidigare (den har tappat sin LBA i och med att den är bortreallokerad och annan spare-sektor tagit över LBA-posten)

Får man 1-2 reallokerade sektorer i 05 i SMART ganska tidigt i diskens liv och det inte sedan stiger i antal över väldigt lång tid så är det inget jag skulle bekymra mig om, men om disken är +50000 timmar och det plötsligt stiger från '0' så skulle jag reagera och sätta disken under observation då när det väl börjar så kommer felen ofta i allt snabbare takt (men bara om disken skriver en massa filer hela tiden) .

En sak att tänka på är att '05' bara ökar för skrivningar som görs och resulterat sektor inte kunde skrivas felfritt och därmed reallokeras.

Vid läsning och den ser tveksamma sektorer som brister i signalstyrka eller nära sin kapacitet för ECC-rättning så ökas post 197 (C5h) "current pending sektors" i SMART men dessa räknas ned igen om sektorerna i fråga skrivs med ny data igen och skulle den skrivningen misslyckas så ökas post 05 igen med 1. Denna värde ökas bara om disken skannar sektorer så att veka sektorer upptäcks och görs typisk med en scrubbing-process i en RAID - så att kolla värdet på post 197 (C5h) då och då när scrubbing görs kan indikera om det är veka (men läsbara) sektorer på disken - men det görs inget åt dem i processen och de är fortsatt veka.

Samma sak om man läser genom fil för fil eller i RAW på undanlagda arkivdiskar - ökar post 197 (C5h) i antal så är det dags för en omskrivning av alla filer på disken då det inte går att få fram vilka sektorer som är svaga på SATA-diskar och skall man bli av med dem så måste hela disken skrivas om (det finns också program som 'diskfresh' som läser in en bunt sektorer på RAW-nivå och sedan skriver tillbaka samma data igen på samma plats och den vägen tvingar en nyskrivning av datat på snurrdiskar, dock gäller det inte alltid på SSD då kontrollern i SSD kan upptäcka att datat är samma som lästes nyss och inget görs)

- Tyvärr kan man inte få reda på vilken LBA-nummer som de problematiska sektorerna finns på disken för post 198 (C5h) och kan prova att läsa och och sedan skriva tillbaka just dessa sektorer igen - vilket görs automagiskt i SAS/SCSI-diskar allt eftersom de upptäcks tex. vid patrolling med läsning av samtliga sektorer på diskytan regelbundet, som i SAS-diskar kan programmeras att göra själv automagiskt i jämna intervaller när disken inte hanterar data - det som med SATA-diskar försöker efterlikna med 'scrubbing' med RAID-mjukvara men där är problemet att inget rättas förrän uppkomna riktiga läsfel och redundansen i RAID rättar sektorn med läsfelet. - medans i SAS-disk rättas den automatiskt innan sektorn i fråga har så många bitfel att den inte kan rättas - och det blir aldrig läsfel. - Med antal bitfel kan en SAS-disk mäta kvaliten på sektorer och ta dessa innan det är ett problem (dvs tappad data) men det finns ingen möjlighet att göra samma sak på SATA-diskar tyvärr.

Därav anledningen om man man har möjlighet med egenbyggd NAS/server och använda HBA i IT-mode (tex. LSI-SAS92xx-seriens diskkontrollerkort), köpa SAS-diskar istället för SATA-diskar då de ofta nu är i nära samma pengar som SATA-diskar med typiskt ett par hundralappar skillnad [1] - speciellt idag om man köper > 10TB diskar då diskarna börja bli så stora att göra scrubbing mjukvarumässigt mha. RAID-mjukvara börja uppta så stor andel av totala tiden att det vore bra att diskarna kunde sköta det själva och man har längre mellanrum för den externa scrubbingen.

[1]
Fast med Chia-miningens explosiva ökning och dammsugning av diskar sista 6 månaderna så kanske det har kullkastat reglerna prisbildsmässigt...