Varför förlorar en hemmaserver en NVMe-enhet först efter att den vaknar från viloläge?
En NVMe-enhet kan försvinna efter viloläge när dess styrenhet eller PCIe-länk inte kan återgå från ett energisnålt läge under återupptagningen.
En enhet som fungerar efter en kallstart men försvinner endast efter försättning i viloläge har vanligtvis inte ett enkelt filsystemproblem. Felet kan uppstå innan namnrymden, partitionen, filsystemet eller programmet blir synligt: PCIe-enheten kanske inte räknas upp igen, NVMe-styrenheten kanske inte blir klar, eller en kombination av energihanteringsinställningar kan göra länken otillgänglig. Diagnostisera det lägsta saknade lagret först och undvik att formatera, byta ut eller återskapa lagring innan enhetens sökväg har fastställts.
Fastställ vilket lägsta lager som försvinner efter återupptagning
Innan viloläge ska du notera PCI-enheten, NVMe-styrenheten, namnrymderna, partitionerna, filsystemens UUID:er, monteringar och program som använder enheten. Upprepa samma kontroller omedelbart efter återupptagningen.
Linux undersystem för NVMe exponerar styrenheter och namnrymder som separata lager. Ubuntus nvme list-kommando hjälper dig att skilja en saknad styrenhet från en styrenhet som fortfarande finns men inte längre exponerar den förväntade namnrymden.
Om PCI-funktionen saknas ska du fokusera på fast programvara, PCIe-länkens energihantering och vilolägesbeteende. Om styrenheten finns kvar men blockenheten försvinner ska du fokusera på NVMe-återställning, namnrymder, drivrutinsfel och om styrenheten blir klar.
Jämför kallstart, omstart och varje stödd typ av viloläge
Testa en kallstart, en vanlig omstart, försättning i inaktivt läge och djupt viloläge, men endast när operativsystemet och den fasta programvaran exponerar dessa lägen. Notera vilken övergång som återskapar felet.
Linuxkärnan skiljer mellan inaktivt viloläge, standby och försättning i RAM, som alla har olika grad av energireduktion för enheter och plattformen. Kärnans beskrivning av vilolägen förklarar varför en NVMe-styrenhet kan återupptas korrekt från ett ytligare läge men misslyckas efter en djupare plattformsövergång.
Ett fel som endast uppstår i ett visst läge är starkare belägg för ett problem med energiövergången än för ett diskformateringsproblem. Behåll det läge som fungerar medan du testar en permanent lösning i fast programvara eller drivrutin.
Kontrollera om PCIe-enheten räknas upp igen
Jämför PCI-bussens utdata före viloläge och efter återupptagning, inklusive NVMe-styrenhetens adress, förhandlat länkläge, kärndrivrutin och felräknare. Spara den exakta bussadressen innan testet.
Verktyget lspci rapporterar styrenheten på PCI-lagret innan någon namnrymd eller något filsystem är inblandat, vilket gör det till rätt skiljemarkör när hela NVMe-enheten verkar försvinna.
Om enheten saknas i PCI-uppräkningen kan en omsökning av filsystemet eller återskapande av monteringar inte hjälpa. Om den fortfarande syns ska du samla in NVMe- och kärnfel innan du försöker återställa styrenheten.
Testa NVMe:s autonoma övergångar mellan energitillstånd
Notera de aktuella inställningarna för NVMe:s energitillstånd och om autonoma övergångar mellan energitillstånd är aktiverade. Ändra endast en energirelaterad variabel under en kontrollerad försättning i viloläge.
ArchWiki dokumenterar NVMe:s energisparbeteende och APST-latenskontrollen, som används för att begränsa hur djupt styrenheten får gå in i energisnåla lägen när viss maskinvara återupptas opålitligt.
En tillfällig APST-begränsning är ett diagnostiskt test, inte ett bevis på att alla djupa lägen är felaktiga. Om enheten överlever upprepade återupptagningar endast med en ytligare energiprofil ska du jämföra lösningar i fast programvara och kärnan innan du behåller kringlösningen permanent.
Granska fast programvara, BIOS och Modern Standby-beteende
Notera versionen av moderkortets fasta programvara, NVMe-enhetens fasta programvara, operativsystemets version och eventuella nyliga BIOS- eller drivrutinsändringar. Kontrollera om plattformen använder traditionellt viloläge eller en modern modell för energisnålt inaktivt läge.
Microsofts Modern Standby-modell visar att stödda enheter förblir under plattformshanterat energisnålt beteende i stället för att följa samma väg som traditionellt viloläge, vilket kan förändra hur ett NVMe-problem återskapas mellan olika system.
Uppdatera ett lager av fast programvara i taget och bevara den tidigare versionen eller en återställningsmetod. Kombinera inte en BIOS-uppdatering, en uppdatering av SSD:ns fasta programvara och en uppgradering av operativsystemet i samma test, eftersom du då inte kan identifiera vilken ändring som lyckades.
Granska PCIe-länkens energihantering och energihantering under drift
Kontrollera inställningar för PCIe ASPM, energistatus under drift och om NVMe-styrenheten går in i ett avstängt energiläge innan systemet försätts i viloläge. Jämför den felande kortplatsen med en annan kortplats endast om serverns konstruktion tillåter det på ett säkert sätt.
Red Hats vägledning om energihantering förklarar att energihantering under drift och PCIe ASPM är separata mekanismer. Om en av dem inaktiveras och en förändring observeras identifierar det därför inte automatiskt den andra som orsaken.
Om problemet följer med enheten till en annan kortplats ska du misstänka styrenheten eller den fasta programvaran. Om det stannar kvar på en kortplats ska du granska moderkortets fasta programvara, bifurkering, delade PCIe-banor, kortplatsens strömförsörjning och signalintegritet.
Återställ säkert och verifiera upprepade återupptagningar
När enheten försvinner ska du bevara loggarna innan du stänger av systemet kallt. Undvik upprepade maskinvaruåterställningar om styrenheten rapporterar kritisk status, länkfel eller försvinnande namnrymder.
ZimaSpaces checklista för återställning av hemserver ger en närliggande regel: verifiera maskinvarans synlighet och lagringens status innan du kör filsystemsreparation eller återställer data.
Problemet är löst när styrenheten, namnrymden, partitionerna, monteringarna och programmen överlever upprepade viloläges- och återupptagningscykler under det avsedda energiläget. Behåll en aktuell säkerhetskopia tills lösningen även överlever omstart, inaktiv tid och normal lagringsbelastning.
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.
