Varför försvinner en SATA-SSD efter en varm omstart men återkommer efter en avstängning?
En SATA-SSD kan försvinna efter en varm omstart när styrenheten eller länken förblir i ett felaktigt tillstånd som bara kan återställas genom att strömmen bryts helt.
En normal omstart återställer programvaran, men kanske inte kopplar bort standbyströmmen från SSD:n, styrenheten, bakplanet eller moderkortets port. Om länken inte blir klar kan enheten försvinna innan partitioner, filsystem, lagringspooler eller program ens är involverade. En fullständig avstängning förändrar felsituationen eftersom den tvingar fram en djupare initiering av styrenhet och länk. Börja med att identifiera det lägsta lagret där enheten försvinner i stället för att omedelbart bygga om lagringen eller ersätta filsystemet.
Ta reda på om BIOS, SATA-styrenheten eller endast operativsystemet tappar SSD:n
Notera om SSD:n visas i BIOS eller UEFI, i operativsystemets vy över styrenheten, i listan över blockenheter, i partitionstabellen och i det monterade filsystemet före och efter en varm omstart.
Linux-guiden för libATA beskriver hur drivrutinen väntar på att en SATA-länk ska bli klar och kan behandla en enhet som frånvarande när den inte blir redo. Dess modell för återställning av SATA-länkar förklarar varför en disk kan försvinna innan filsystemslagret ens nås.
Om BIOS också tappar SSD:n bör du fokusera på fast programvara, portström, länkinitiering, kabeln och enhetens styrenhet. Om BIOS ser den men operativsystemet inte gör det ska du bevara operativsystemets loggar och granska drivrutinernas identifiering av enheter samt styrenhetens läge.
Jämför varm omstart, fullständig avstängning och bortkopplad ström
Testa en vanlig omstart, en avstängning via operativsystemet följd av omedelbar uppstart och en avstängning där strömmen kopplas bort tillräckligt länge för att standbyspänningarna ska falla. Upprepa varje tillstånd minst två gånger.
Vyn över PCI-enheter ger en tydlig gräns mellan styrenhetens närvaro och lagringsidentifieringen. Verktyget lspci kan bekräfta om själva AHCI- eller SATA-styrenheten ändrades efter omstarten, även när SSD:ns blockenhet saknas.
Om endast ett fullständigt strömbortfall återställer enheten är de främsta kandidaterna ett kvarstående tillstånd i styrenheten, en ofullständig återställning av SATA-fysiklagret, SSD:ns programvara eller en interaktion med strömhanteringen. Det mönstret stämmer sämre med ett vanligt monterings- eller partitionsproblem.
Granska den första SATA-länken och återställningsfelet
Spara kärnans eller systemets händelselogg från den misslyckade varma omstarten innan du gör en kallstart. Leta efter meddelanden om att länken gått ned, COMRESET-fel, tidsgränser för att enheten ska bli redo, misslyckade IDENTIFY-kommandon eller upprepade portåterställningar.
SATA:s aktiva länkhastighetsstyrning kan försätta länken i energisnåla lägen som vissa kombinationer av styrenhet och SSD hanterar dåligt. ArchWiki varnar för att aggressiv länkhastighetsstyrning kan orsaka allvarliga problem med inkompatibla enheter.
Det första felet är mer värdefullt än senare meddelanden om att filsystemet eller lagringspoolen inte är tillgänglig. Spara portnumret och enhetsmodellen så att alla senare tester av kablar, platser och fast programvara kan kopplas till samma anslutningsväg.
Kontrollera SATA-kabeln, strömkontakten och räknarna för gränssnittsfel
Sätt tillbaka SATA-datakabeln och strömkontakten när servern är helt avstängd. Kontrollera lösa låsflikar, skarpa böjar, splitters, bakplanskontakter och adaptrar.
Unraids vägledning för felsökning av lagring anger att ökande UDMA CRC-fel bör leda till kontroller av datakablar, strömkablar, styrenhetsanslutningar och portar i stället för omedelbar reparation av filsystemet.
En historisk CRC-räknare bevisar inte att den aktuella kabeln fortfarande är dålig. Notera råvärdet, genomför en kontrollerad omstartscykel och kontrollera om räknaren ökar.
Granska SSD:ns SMART-data, felloggar och programvarustatus
Samla in SSD:ns modell, serienummer, version av fast programvara, antal strömcykler, antal osäkra avstängningar, gränssnittsfel och tillgängliga enhetsloggar över fel när enheten är synlig.
Referensen för smartctl beskriver SMART-attribut och felloggar som hjälper till att skilja problem med flashminnets hälsa från fel i transport eller styrenhet.
Installera en uppdatering av SSD:ns fasta programvara först efter att du har verifierat säkerhetskopior, modellkompatibilitet och leverantörens återställningsinstruktioner. Ändra en nivå av fast programvara i taget så att du kan identifiera en lyckad åtgärd.
Använd omsökning endast som diagnostik
När styrenheten fortfarande finns men disken saknas kan du göra en stödd omsökning av lagringen efter att all aktiv I/O har stoppats. Notera om SSD:n återkommer utan en strömcykel.
Microsoft dokumenterar att DiskParts kommando för omsökning hittar nyligen identifierade diskar, vilket gör det användbart för att skilja fördröjd identifiering i operativsystemet från en enhet som saknas på styrenhetsnivå.
En lyckad omsökning är ingen permanent lösning. Den visar att styrenheten och SSD:n kan kommunicera efter ytterligare ett identifieringsförsök, så det återstående arbetet hör hemma i fast programvara, drivrutin, styrenhetsläge eller länkinitiering.
Isolera enheten, porten och styrenheten innan du byter ut något
När du har säkerhetskopierat data flyttar du SSD:n till en fungerande SATA-port med en fungerande kabel, eller testar en fungerande enhet i den ursprungliga anslutningsvägen. Ändra endast en komponent per cykel.
ZimaSpaces guide om att skilja SATA-kabel- och enhetsfel åt beskriver ett närliggande isoleringsförfarande för lagringsvägar som fallerar sporadiskt.
Problemet är löst när SSD:n förblir synlig genom upprepade varma omstarter, kallstarter, perioder av inaktivitet och långvarig läsning utan nya länkfel. Sluta använda enheten för primärdata om den fortsätter att försvinna via fungerande portar och kablar eller rapporterar förvärrade enhetsfel.
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.
