Perché un server domestico perde un’unità NVMe solo dopo il risveglio dalla sospensione?
Un’unità NVMe può scomparire dopo la sospensione quando il controller o il collegamento PCIe non riescono a uscire da uno stato a basso consumo durante la ripresa.
Un’unità che funziona dopo un avvio a freddo ma scompare solo dopo la sospensione di solito non presenta un semplice problema del filesystem. Il guasto può verificarsi prima che siano visibili il namespace, la partizione, il filesystem o l’applicazione: il dispositivo PCIe potrebbe non essere enumerato nuovamente, il controller NVMe potrebbe non riuscire a diventare pronto oppure una combinazione di impostazioni di gestione dell’alimentazione potrebbe lasciare il collegamento inaccessibile. Diagnostica prima il livello più basso che manca ed evita di formattare, sostituire o ricostruire lo storage finché il percorso del dispositivo non è stato compreso.
Determina il livello più basso che scompare dopo la ripresa
Prima della sospensione, registra il dispositivo PCI, il controller NVMe, i namespace, le partizioni, gli UUID dei filesystem, i mount e le applicazioni che utilizzano l’unità. Ripeti gli stessi controlli immediatamente dopo la ripresa.
Il sottosistema NVMe di Linux espone controller e namespace come livelli separati. Il comando nvme list di Ubuntu aiuta a distinguere un controller mancante da un controller che rimane presente ma non espone più il namespace previsto.
Se la funzione PCI è assente, concentrati sul firmware, sull’alimentazione del collegamento PCIe e sul comportamento durante la sospensione. Se il controller rimane presente ma il dispositivo a blocchi scompare, concentrati sul reset NVMe, sui namespace, sugli errori del driver e sulla disponibilità del controller.
Confronta avvio a freddo, riavvio e ogni stato di sospensione supportato
Testa un avvio a freddo, un normale riavvio, la sospensione a basso consumo e la sospensione profonda, ma solo quando il sistema operativo e il firmware le espongono. Registra quale transizione riproduce il problema.
Il kernel Linux distingue tra sospensione a basso consumo, standby e sospensione su RAM, ognuna con un diverso livello di riduzione dei consumi del dispositivo e della piattaforma. La descrizione degli stati di sospensione del kernel spiega perché un controller NVMe può riprendersi correttamente da uno stato superficiale ma non dopo una transizione più profonda della piattaforma.
Un guasto limitato a un solo stato è una prova più forte di un problema nella transizione di alimentazione che di un problema di formattazione del disco. Mantieni disponibile lo stato che funziona durante i test di una correzione permanente del firmware o del driver.
Verifica se il dispositivo PCIe viene enumerato nuovamente
Confronta l’output del bus PCI prima della sospensione e dopo la ripresa, includendo l’indirizzo del controller NVMe, lo stato del collegamento negoziato, il driver del kernel e i contatori degli errori. Salva l’indirizzo esatto del bus prima del test.
L’utilità lspci segnala il controller a livello PCI prima che siano coinvolti namespace o filesystem, rendendola lo strumento corretto per distinguere il caso in cui l’intero dispositivo NVMe sembri scomparire.
Se il dispositivo manca dall’enumerazione PCI, una nuova scansione del filesystem o la ricreazione dei mount non possono essere d’aiuto. Se rimane visibile, acquisisci gli errori NVMe e del kernel prima di tentare un reset del controller.
Verifica le transizioni autonome dello stato di alimentazione NVMe
Registra le impostazioni attuali degli stati di alimentazione NVMe e se le transizioni autonome dello stato di alimentazione sono abilitate. Modifica una sola variabile relativa all’alimentazione per ogni ciclo di sospensione controllato.
ArchWiki documenta il comportamento del risparmio energetico NVMe e il controllo della latenza APST, utilizzato per limitare la profondità con cui il controller può entrare negli stati a basso consumo quando determinati hardware riprendono in modo inaffidabile.
Una limitazione temporanea di APST è uno strumento diagnostico, non la prova che ogni stato profondo sia difettoso. Se l’unità sopravvive a cicli ripetuti di ripresa solo con una politica di alimentazione più superficiale, confronta le correzioni del firmware e del kernel prima di mantenere permanentemente la soluzione temporanea.
Esamina il comportamento del firmware, del BIOS e della modalità Modern Standby
Registra la versione del firmware della scheda madre, il firmware NVMe, la build del sistema operativo ed eventuali modifiche recenti al BIOS o al driver. Verifica se la piattaforma utilizza la sospensione tradizionale o un modello di inattività moderno a basso consumo.
Il modello Modern Standby di Microsoft mostra che i dispositivi supportati rimangono soggetti a un comportamento a basso consumo gestito dalla piattaforma, invece di seguire lo stesso percorso della sospensione tradizionale; ciò può cambiare il modo in cui un problema NVMe si riproduce tra sistemi diversi.
Aggiorna un solo livello firmware alla volta e conserva la versione precedente o un metodo di ripristino. Non combinare un aggiornamento del BIOS, un aggiornamento del firmware dell’SSD e un aggiornamento del sistema operativo nello stesso test, perché non sarebbe possibile identificare la modifica risolutiva.
Controlla l’alimentazione del collegamento PCIe e la gestione dell’alimentazione in modalità runtime
Controlla le impostazioni ASPM PCIe, lo stato dell’alimentazione in modalità runtime e se il controller NVMe entra in uno stato runtime sospeso prima della sospensione del sistema. Confronta lo slot che presenta il problema con un altro slot solo se la progettazione del server lo consente in sicurezza.
La guida alla gestione dell’alimentazione di Red Hat spiega che la gestione dell’alimentazione runtime e l’ASPM PCIe sono meccanismi distinti; pertanto, disabilitarne uno e osservare un cambiamento non identifica automaticamente l’altro come causa.
Se il problema segue l’unità in un altro slot, sospetta il controller o il firmware. Se rimane associato a uno slot specifico, esamina il firmware della scheda madre, il bifurcation, le linee condivise, l’alimentazione dello slot e l’integrità del segnale.
Recupera i dati in sicurezza e verifica cicli ripetuti di ripresa
Quando l’unità scompare, conserva i log prima di eseguire uno spegnimento a freddo. Evita reset a caldo ripetuti se il controller segnala uno stato critico, errori del collegamento o namespace scomparsi.
La lista di controllo per il ripristino del server domestico di ZimaSpace fornisce la regola correlata: verifica la visibilità dell’hardware e lo stato dello storage prima di eseguire la riparazione del filesystem o ripristinare i dati.
Il problema è risolto quando il controller, il namespace, le partizioni, i mount e le applicazioni superano cicli ripetuti di sospensione e ripresa nello stato di alimentazione previsto. Mantieni un backup aggiornato finché la correzione non supera anche un riavvio, un periodo di inattività e il normale carico dello storage.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
