Varför kan en enhet rapportera SMART GODKÄND men ändå misslyckas vid samma LBA under ett fullständigt lästest?
En enhet kan rapportera SMART GODKÄND och ändå misslyckas med en fullständig läsning, eftersom tröskeln för den övergripande hälsostatusen inte garanterar att varje sektor fortfarande är läsbar.
SMART-raden för övergripande hälsa sammanfattar leverantörsdefinierade feltrösklar. Det betyder inte att hela ytan lästes under den kontrollen. Ett fullständigt lästest berör betydligt fler adresser och kan upptäcka en lokal sektor som inte kan korrigeras, ett svagt läshuvud, ett problemområde i flashminnet, en timeout, ett kabelproblem eller en återställning av styrenheten. Den mest användbara informationen är om felet återkommer på samma LBA och följer med enheten när anslutningsvägen ändras.
Skilj mellan övergripande SMART-hälsa och resultaten från självtest
Spara hela SMART-rapporten, inte bara den avslutande raden GODKÄND. Ta med attribut, felloggar, historik över självtester, väntande sektorer, sektorer som inte kan korrigeras, CRC-fel och temperatur.
Smartmontools påpekar att en enhet kan behålla statusen SMART GODKÄND efter ett misslyckat självtest när en skadad eller okorrigerbar sektor ännu inte har överskridit leverantörens övergripande feltröskel.
Om självtestloggen redan visar en felande LBA ska du spara den innan du kör fler tester. Resultatet för den övergripande hälsan ska inte väga tyngre än specifika bevis från lagringsmediet eller testerna.
Förstå vad ett fullständigt lästest tillför
Notera testverktyg, läsläge, blockstorlek, start-LBA, stopp-LBA, förfluten tid och om verktyget försöker läsa om misslyckade läsningar. Bekräfta att testet är skrivskyddat.
Seagate förklarar att deras Long Generic läser varje sektor, vilket är anledningen till att det kan hitta ett lokalt problem som missas av en kort hälsokontroll.
Ett fel vid fullständig läsning är mer användbart att analysera när det uppstår på samma adress upprepade gånger. Ett fel som flyttar sig mellan adresser eller bara visas genom ett visst kabinett kan i stället tyda på instabilitet i överföring, strömförsörjning eller styrenhet.
Jämför med ett utökat test från en annan leverantör
När enheten är tillräckligt stabil och data är skyddad kör du tillverkarens rekommenderade utökade diagnostik eller medieskanning. Spara dess kod och logg.
Western Digital beskriver ett utökat test som ett grundligt enhetstest, vilket gör det användbart för att bekräfta att ett generiskt läsfel inte bara beror på ett visst verktyg.
Belasta inte upprepade gånger en enhet som innehåller den enda kopian av viktig data. När felen ökar är det säkrare att avbilda läsbara områden än att samla in mer bekräftelse.
Koppla den felande LBA:n till enhetens egna loggar
Jämför adressen för felet vid fullständig läsning med SMART-självtestloggen, ATA-felloggen, förändringar av väntande sektorer och systemets I/O-fel. Notera om samma LBA eller ett närliggande område återkommer.
Debians smartctl-referens beskriver utdata från självtester och felloggar som kan bevara den första felande logiska blockadressen.
En adress som återkommer talar för lokal skada på lagringsmediet. Slumpmässiga adresser i kombination med CRC-fel, länkåterställningar eller att enheten försvinner talar för anslutningsvägen eller styrenheten.
Använd ett skrivskyddat yttest med försiktighet
Kontrollera att det valda verktyget är i skrivskyddat läge och att det riktas mot rätt enhet. Använd aldrig ett destruktivt test med skrivmönster på en disk som innehåller data du behöver.
Handboken för badblocks skiljer mellan skrivskyddad skanning och destruktiva skrivlägen, vilket är viktigt innan du testar en disk som innehåller data.
En ytskanning reparerar inte enheten. Den mäter läsbarheten under de aktuella förhållandena, och upprepade försök kan öka belastningen på en enhet som håller på att gå sönder.
Skilj mellan fel på lagringsmediet och fel på kabel, strömförsörjning eller styrenhet
När data är skyddad upprepar du en kort, avgränsad läsning runt det felande området via en fungerande kabel, en direktansluten port, en stabil strömförsörjning och, när det är praktiskt möjligt, en annan styrenhet.
GNU ddrescue är utformat för att rädda läsbara områden först samtidigt som förloppet registreras, vilket är säkrare än att upprepade gånger starta om en vanlig fullständig läsning mot en instabil disk.
Om samma LBA misslyckas via fungerande anslutningsvägar är enheten den gemensamma komponenten. Om felet försvinner eller ändras när anslutningsvägen ändras bör du undersöka strömförsörjning, kabel, brygga, HBA och värdsystemets loggar.
Skydda data innan du avgör om enheten ska bytas ut
Avsluta onödiga tester när felen ökar, enheten återställs, antalet väntande eller okorrigerbara sektorer i SMART ökar eller enheten innehåller data som inte kan ersättas. Kopiera eller avbilda läsbar data först.
ZimaSpaces guide om en dålig SATA-kabel jämfört med en felande enhet behandlar det närliggande beslutet om att isolera anslutningsvägen. Den här artikeln fokuserar på varför SMART GODKÄND och ett resultat från en fullständig ytläsning kan skilja sig åt.
Enheten bör tas ur primär drift när återkommande oläsbara områden, misslyckade utökade tester, försämrade enhetsloggar eller fel som följer serienumret kvarstår efter att anslutningsvägen har kontrollerats.
Vanliga frågor
Betyder SMART GODKÄND att enheten är frisk?
Det betyder att enheten inte har överskridit leverantörens övergripande feltröskel. Det garanterar inte att varje LBA är läsbar eller att det inte finns något intermittent elektronik- eller överföringsfel.
Är ett fullständigt lästest destruktivt?
En skrivskyddad skanning är inte avsedd att ändra data, men den kan belasta en svag enhet. Yttester med skrivmönster är destruktiva och får aldrig användas på data som behövs.
Bör jag försöka läsa samma felande sektor många gånger?
Nej. Upprepade försök kan slösa tid och belasta instabila lagringsmedier. Spara det första felet, skydda läsbar data och använd ett återställningsinriktat verktyg när datan är viktig.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
