Varför följer NAS-scrubbfel en och samma kontrollerport för olika enheter?
Scrubfel som följer en och samma styrport över flera enheter pekar vanligtvis på den gemensamma anslutningsvägen snarare än på diskarnas lagringsmedia.
En scrub läser ett stort antal block och kan upptäcka fel som vanlig daglig åtkomst aldrig når. Om olika, bevisat felfria enheter bara får fel när de ansluts via samma port omfattar de gemensamma komponenterna styrkanalen, kontakten, kabeln, backplane-länken, expandervägen, strömförsörjningen, den fasta programvaran och kylningen runt denna väg. Diagnosen måste visa att felet följer porten, samtidigt som enhetsidentitet, tidsstämplar och feltyp bevaras.
Bekräfta att felet följer porten, inte enhetsnamnet
Registrera enheternas serienummer, stabila enhets-ID:n, styrport eller HBA-PHY, kabel, fack, poolmedlem samt läs-, skriv- och kontrollsummeräknare före nästa scrub. Förlita dig inte enbart på ändrade namn som /dev/sdX.
TrueNAS felsökningsflöde för enheter betonar att pool- och SMART-information ska samlas in innan fel rensas eller en enhet byts ut.
Efter ett byte när systemet varit avstängt, undersök om felet följer enheten, facket, kabeln eller styrporten. Ändra bara en komponent per test så att resultatet förblir tolkningsbart.
Separera kontrollsummefel från läs- och skrivfel på enheten
Spara det fullständiga scrubresultatet och räknarna för varje enhet. En kontrollsummemiss, ett kommandotidsgränsöverskridande, en oläsbar sektor och en misslyckad skrivning representerar olika fellager.
Oracle dokumenterar att en ZFS-scrub verifierar kontrollsummor för aktiva data, medan poolstatus separat rapporterar läs-, skriv- och kontrollsummefel för varje enhet.
Om kontrollsummefelen ökar utan mediefel och följer en fysisk anslutningsväg, misstänk datakorruption mellan minnet och enheten eller en instabil överföring. Om läsfelen följer enheten mellan olika portar blir det mer sannolikt att disken är orsaken.
Kartlägg disken till exakt styrenhet och länk
Följ den stabila disksökvägen genom värddatorns styrenhet, PCI-adress, SAS-expander eller SATA-port, chassi, kabel och fack. Spara kartläggningen innan du flyttar hårdvara.
lspci-enhetsvyn identifierar PCI-lagringsstyrenheten oberoende av filsystem- och poolnamn, vilket hjälper dig att skilja en felande styrväg från en disk som bara har fått ett nytt enhetsnamn.
För en HBA ska du inkludera PHY- och expanderinformation när den är tillgänglig. Två främre fack kan dela på en mini-SAS-kabel eller expanderlänk även om användargränssnittet visar dem som separata platser.
Kontrollera SATA- eller SAS-länkåterställningar under scrub
Övervaka kärnloggen från det ögonblick scrub startar. Leta efter hårda återställningar, COMRESET-fel, länkavbrott, kommandotidsgränser, protokollfel och ändringar av förhandlad hastighet på den berörda vägen.
Linux-guiden för libATA beskriver återställning och felhantering per länkport, vilket visar varför upprepade meddelanden knutna till en ATA-port är starkare bevis än en generell poolvarning.
Bevara det första överföringsmeddelandet. Senare filsystemfel kan bara vara följder av att styrenheten tappade kommunikationen under en läsning.
Jämför räknare för gränssnitts-CRC och kommandotidsgränser
Samla in SMART-attribut och loggar för varje enhet före och efter en scrub. Följ om gränssnitts-CRC- eller kommandotidsgränsräknarna ökar endast på den berörda vägen.
Unraid förklarar att UDMA-CRC-fel uppstår mellan enheten och styrenheten och vanligtvis pekar på kablar, kontakter, kabeldragning eller styrenhetslänken snarare än skador på lagringsskivorna.
Historiska CRC-summor identifierar inte den aktuella komponenten. Registrera råvärdet, kör ett avgränsat test och kontrollera endast om värdet har ökat.
Kör enhetstester separat från scrub-belastningen
Kör korta och utökade SMART-tester som stöds när poolen i övrigt är lugn och data är skyddad. Undvik att schemalägga ett fullständigt SMART-test samtidigt som en annan scrub eller återuppbyggnad.
Debians smartctl-referens skiljer mellan interna självtester och felloggar för enheten och värdsidebaserad filsystemsverifiering.
En enhet som klarar ett internt test men bara ger fel på en styrport stärker hypotesen om ett problem i anslutningsvägen. Det bevisar inte att disken är felfri, så fortsätt övervaka efter att porten har bytts.
Byt en gemensam komponent och upprepa en avgränsad scrub
Se till att säkerhetskopiorna är aktuella och stäng av servern. Flytta en bevisat felfri enhet genom den misstänkta vägen eller byt en kabel, samtidigt som övriga variabler hålls konstanta. Flytta inte alla diskar samtidigt.
ZimaSpaces guide om en frånkopplad disk jämfört med ett felaktigt diskfack beskriver den närliggande metoden för kontrollerade byten. Den här artikeln tillämpar samma logik specifikt på scrubfel som upprepade gånger följer en styrport.
Avbryt scrub och prioritera dataskyddet om felen ökar snabbt, flera enheter på samma styrenhet återställs, poolen försämras eller program rapporterar skadade filer. Problemet är löst först när samma portväg har genomfört upprepade scrubkörningar och normal I/O utan nya fel.
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.
