Hur kritiskt är EN dålig sektor?

Kan du få fram SMART-värdena på disken - alla poster även RAW

---

Ser ingen reallokerad sektor, det borde RAID-systemet - om den är redundant (RAID1, RAID5, RAID6, RAID10, RAID60) ha provat att skriva om den dåliga sektorn som antingen självläker eller så ökar reallokeringen med 1 steg (dock uppräkning i läsmisslyckaden kommer att vara kvar för alltid i SMART)

Om det är Jbod eller RAID0 så kan den inte reparera och en sektor är då oläslig (ger fel vid läsning) och du har troligen en fil som har en skadad sektor.

Om den kör på BTRFS och icke redundant RAID så kommer det märkas då den spärrar på filen med IO-fel då checksummor inte stämmer vid läsning om det misslyckas igen vid läsning medans är det ext4 så kommer det vara svårt att jaga efter vilken fil som har skadan och det är möjligen att hoppas på en I/O-fel vid läsning. I BTRFS kommer det finnas en post i dmesg och log vid läsfel, och man kan ta det värdet och fråga btrfs vilken fil felet hörde till om det inte redan framgår i dmesg i raderna före och efter.

---

läsfel händer rent statistiskt då och då på alla diskar - det är detta som står BER 1*10^-14 i databladet för sannolik av icke rättningsbara fel, vilket ger ett ej rättningsbar fel per 11TB läst i genomsnitt och läser man tillräckligt med data så kommer man springa på det förr eller senare - därav RAID med redundans.

Men om sektorn vid nya försök går att läsa ändå eller att RAID med redundans rättar den dåliga sektorn så är det inte så stort att man skall dunka panik-knappen som många program dessvärre gör. - och många disktillverkare vill att det skall vara så mycket fel och reallokeringar att SMART larmar själv (dvs. värde under treshold i SMART-tabellen) innan de godkänner RMA - ofta måste ett program från disktillverkaren testa disken och vid godkänd mycket fel ger en unikt nummer som är underlaget för RMA - och det kommer inte att kunna göras RMA på en enda läsfel!

Det som är intressant är om det börja bli liknande händelse mer ofta, börja få reallokerade sektorer i allt högre takt - då är det dags att fundera på ny disk - och om man inte har redundans, definitivt överväga det eller har backup med generationer som kan återställa den filen som nu kanske fått IO-fel vid läsning.

En sak till är att SATA-diskar fräschar aldrig upp en halvdålig sektor - omskrivning sker bara vid skrivning om verifieringen i samband med skrivningen blir för låg kvalitet - aldrig i efterhand oavsett hur många gånger man läser på den havldåliga sektorn (sådant gör SAS-diskar automagiskt, dessutom långt innan sektorn blir oläsbar! - tyvärr har folk fått för sig att det gäller också SATA-snurrdiskar, vilket är fel såvida det inte gäller SSD/NVMe då man tvingades att stoppa dit patrolling och mäta hur snabb sektorer går att läsa i jämna intervall och skriva om vid behov då flasminnescellerna blev för snabbt risiga)

Om man i BTRFS kör 'balance' utan argument så flyttas varenda sektor med data i sig och därmed blir det nyskrivet på alla sektorer och är ett sätt att fräscha upp datat som legat orörligt på disken länge - men som alltid skall man ha backup på det innan då man kan stöta på fler ruvande fel om man inte har gjort scrub av disken regelbundet (också en orsak till att ha redundans - blir det läsfel på disken så kan datat lagas med de andra diskarnas hjälp - medans med JBOD/RAID0 har man trasiga filer istället)

Verkar som att du kör en RAID5

lite ögonbrynshöjaren här är de ganska många hårda läsfelen som samlats på med tiden i post 1, det är normalt att det kan komma enstaka sådana över åren och kanske lite mer ofta vid mycket läsning hela tiden (men inte tätare än 1 per drygt 11 TB läst datamängd), men 28 är mer än förväntat.

WD-red är angiven till BER 1*10^-14 så det skall inte ge mer än 1 ej korrekterbar fel per lite drygt 11 TB läst data

Frågan är om det är alla har kommit på kort tid eller om det plockat enstaka under lång tid - något har i alla fall triggat OS och gissar att det kommit många över kort tid.

Varningen är inte initierad av SMART på disken då det är mycket långt kvar till att det går under några tresholds (kolumn 3) och i princip så är det ingen godkänd RMA om det inte gått under tresholds även om diskbyte ofta görs med mycket mindre än så på goodwill-nivå.

varningen är alltså gjort av Synology-miljön själv med hårdare satta regler och är mycket grinigare och skriker för minsta fel.

---

vad som skall göras - Det självklara - kolla att dina backupper är uppdaterade och nysynkade mot NAS:en - har du inte backup - ja då är det dags med en 16 TB USB-disk - det NU!

varför backup då ?

jo skall du köra scrub, byta disk eller rentav göra en fullbackup så är talesättet att 'olyckor kommer i sällskap' högst relevant. Med andra ord när man börja läsa alla filer så finns disken att man stöter på fler problem - speciellt om du inte kört scrub på väldigt lång tid.

Att göra fullbackupp i ett läge när en NAS redan har problem så är man redan satt i ett ofördelaktigt läge av anledningen när man läser alla filer så är det läsa nästan lika noga som att göra en scrub och har man latenta fel på flera diskar utlöses av läsningen och det råkar bli på samma LBA-nummer så kommer det bli krångel, läsfel och förlorade filer.

gör man synkning på en redan tidigare gjord backup med tex. rsync - ja då är det ytterst lite som behöver kompletteras och chansen att lyckas är maximal.

när man är klar med backuppen och allt verkar OK - ja det är att göra som det står - att initiera en extended test.

Detta måste göras off-line - jag skulle bara ta ut den problematiska disken ur NAS:en under drift utan att stänga av och man får köra på 3 diskar utan redundans ett tag.

- den trubbliga disken körs sedan helst i en USB-docka och i linux starta den utökade testen med "sudo smartctl -t long /dev/sdx" i en terminalfönster där är sdx någon av /dev/sda, /dev/sdb... vilket kan kollas fram med 'lsblk' för aktuella USB-disk dockan. när tetsten börja så brukar också förväntad klartid anges

efter testet får man köra igen smartctr -a /dev/sdx och se vad som står i rapporten.

Du kan också använda WD:s diagnostikprogram för att starta den testen under windows - när den är igång så kan man göra annat i 8-12 timmar beroende när den är klar - detta tar tid då diskontrollern kontrollerar hela diskytan.

Är det inga fel rapporterat - så skulle jag bara trycka tillbaka disken i NAS igen och låta RAID:en synka upp sig igen och sedan tittar du åter igen på smart och se om antalet oläsbara sektorer samt reallokerade sektorer har ökat i antal efter ett dygn eller två.

sedan får du hålla ett öga på disken i fortsättningen och har du inte schemalagt en scrub på typ månadsbasis tidigare - så är det nog dags nu och då lär du få reda på om sagda disken fortsätter att bråka närmaste tiden framöver..