Waarom verliest een thuisserver pas na het ontwaken uit de slaapstand één NVMe-schijf?
Een NVMe-schijf kan na de slaapstand verdwijnen wanneer de controller of PCIe-koppeling tijdens het hervatten niet terugkeert uit een energiebesparende toestand.
Een schijf die na een koude start werkt maar alleen na opschorten verdwijnt, heeft meestal geen eenvoudig probleem met het bestandssysteem. De fout kan optreden voordat de naamruimte, partitie, het bestandssysteem of de toepassing zichtbaar is: het PCIe-apparaat wordt mogelijk niet opnieuw geïnventariseerd, de NVMe-controller wordt mogelijk niet gereed, of een combinatie van energiebeheer kan de koppeling ontoegankelijk maken. Stel eerst vast op welke laag het probleem ontstaat en formatteer, vervang of herstel de opslag pas wanneer het apparaatpad duidelijk is.
Bepaal welke laag na het hervatten als laagste verdwijnt
Leg vóór de slaapstand het PCI-apparaat, de NVMe-controller, naamruimten, partities, UUID's van bestandssystemen, koppelingen en toepassingen die de schijf gebruiken vast. Herhaal dezelfde controles onmiddellijk na het hervatten.
Het Linux-NVMe-subsysteem toont controllers en naamruimten als afzonderlijke lagen. De Ubuntu-opdracht nvme list helpt onderscheid te maken tussen een ontbrekende controller en een controller die nog aanwezig is maar de verwachte naamruimte niet langer beschikbaar stelt.
Als de PCI-functie ontbreekt, richt je dan op firmware, PCIe-koppelingsenergiebeheer en het slaapstandgedrag. Als de controller aanwezig blijft maar het blokapparaat verdwijnt, richt je dan op NVMe-reset, naamruimten, stuurprogrammafouten en het gereedkomen van de controller.
Vergelijk een koude start, herstart en elke ondersteunde slaapstand
Test een koude start, een gewone herstart, opschorten naar inactief en diepe opschorting, maar alleen wanneer het besturingssysteem en de firmware deze toestanden beschikbaar maken. Leg vast bij welke overgang de fout optreedt.
De Linux-kernel maakt onderscheid tussen opschorten naar inactief, stand-by en opschorten naar RAM. Elk daarvan gebruikt een ander niveau van energievermindering voor apparaten en het platform. De beschrijving van slaaptoestanden van de kernel verklaart waarom een NVMe-controller vanuit een ondiepe toestand correct kan hervatten maar na een diepere platformovergang kan falen.
Een fout die tot één toestand beperkt blijft, wijst sterker op een probleem met de energieovergang dan op een probleem met de schijfindeling. Houd de toestand die aantoonbaar werkt beschikbaar tijdens het testen van een permanente firmware- of stuurprogrammaoplossing.
Controleer of het PCIe-apparaat opnieuw wordt geïnventariseerd
Vergelijk de uitvoer van de PCI-bus vóór de slaapstand en na het hervatten, inclusief het adres van de NVMe-controller, de overeengekomen verbindingsstatus, het kernelstuurprogramma en de fouttellers. Sla het exacte busadres vóór de test op.
Het hulpprogramma lspci rapporteert de controller op PCI-niveau voordat naamruimten of bestandssystemen een rol spelen. Daarmee is het de juiste onderscheidende controle wanneer het volledige NVMe-apparaat lijkt te verdwijnen.
Als het apparaat ontbreekt in de PCI-inventarisatie, kunnen het opnieuw scannen van het bestandssysteem of het opnieuw aanmaken van koppelingen niet helpen. Als het zichtbaar blijft, leg dan de NVMe- en kernelmeldingen vast voordat je een controllerreset probeert.
Test autonome energietoestandsovergangen van NVMe
Leg de huidige instellingen voor NVMe-energietoestanden vast en noteer of autonome overgangen tussen energietoestanden zijn ingeschakeld. Wijzig per gecontroleerde opschortingscyclus slechts één energiegerelateerde variabele.
ArchWiki beschrijft NVMe-energiebesparing en de APST-latentie-instelling, waarmee je kunt beperken hoe diep de controller energiebesparende toestanden mag binnengaan wanneer specifieke hardware onbetrouwbaar hervat.
Een tijdelijke APST-beperking is een diagnosemiddel en geen bewijs dat elke diepe toestand defect is. Als de schijf alleen met een minder diepe energie-instelling meerdere hervatcycli doorstaat, vergelijk dan firmware- en kerneloplossingen voordat je de tijdelijke oplossing permanent toepast.
Controleer firmware, BIOS en Modern Standby
Noteer de firmwareversie van het moederbord, de NVMe-firmware, de build van het besturingssysteem en recente wijzigingen aan het BIOS of stuurprogramma's. Controleer of het platform traditionele slaapstand of een modern model voor energiezuinige inactiviteit gebruikt.
Het Modern Standby-model van Microsoft laat zien dat ondersteunde apparaten onder platformgestuurd energiebeheer blijven, in plaats van hetzelfde pad als traditionele slaapstand te volgen. Daardoor kan een NVMe-probleem zich op verschillende systemen anders voordoen.
Werk telkens slechts één firmwarelaag bij en bewaar de vorige versie of herstelmethode. Combineer een BIOS-update, SSD-firmware-update en upgrade van het besturingssysteem niet in één test, omdat je anders niet kunt vaststellen welke wijziging het probleem heeft opgelost.
Controleer PCIe-koppelingsenergiebeheer en runtime-energiebeheer
Controleer de instellingen voor PCIe ASPM, de runtime-energiestatus en of de NVMe-controller vóór de slaapstand in een opgeschorte runtime-toestand terechtkomt. Vergelijk de probleemslot met een andere slot, maar alleen als het serverontwerp dit veilig toestaat.
De richtlijnen voor energiebeheer van Red Hat leggen uit dat runtime-energiebeheer en PCIe ASPM afzonderlijke mechanismen zijn. Als het uitschakelen van één ervan een verandering oplevert, betekent dat dus niet automatisch dat dit mechanisme de oorzaak is.
Als het probleem met de schijf naar een andere slot meeverhuist, verdenk dan de controller of firmware. Blijft het probleem bij één slot, controleer dan de moederbordfirmware, bifurcatie, gedeelde lanes, slotvoeding en signaalintegriteit.
Herstel veilig en controleer herhaalde hervatcycli
Wanneer de schijf verdwijnt, bewaar dan de logboeken voordat je het systeem koud uitschakelt. Vermijd herhaalde resets terwijl het systeem actief is als de controller een fatale status, verbindingsfouten of verdwijnende naamruimten meldt.
De herstelchecklist voor thuisservers van ZimaSpace hanteert dezelfde aangrenzende regel: controleer de zichtbaarheid van de hardware en de opslagstatus voordat je een bestandssysteemreparatie uitvoert of gegevens terugzet.
Het probleem is opgelost wanneer de controller, naamruimte, partities, koppelingen en toepassingen meerdere slaapstand- en hervatcycli doorstaan met de bedoelde energietoestand. Houd een actuele back-up aan totdat de oplossing ook een herstart, langere inactiviteit en normale opslagbelasting doorstaat.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
