Perché un SSD SATA scompare dopo un riavvio a caldo ma ricompare dopo lo spegnimento?
Un SSD SATA può scomparire dopo un riavvio a caldo quando il controller o il collegamento rimangono in uno stato anomalo che solo la completa rimozione dell’alimentazione riesce a cancellare.
Un normale riavvio reimposta il software, ma potrebbe non rimuovere l’alimentazione di standby dall’SSD, dal controller, dal backplane o dalla porta della scheda madre. Se il collegamento non diventa pronto, l’unità può scomparire prima che siano coinvolti partizioni, filesystem, pool o applicazioni. Uno spegnimento completo modifica la diagnosi perché forza un’inizializzazione più profonda del controller e del collegamento. Inizia identificando il livello più basso in cui il dispositivo viene perso, invece di ricostruire immediatamente lo spazio di archiviazione o sostituire il filesystem.
Determina se l’SSD viene perso dal BIOS, dal controller SATA o solo dal sistema operativo
Registra se l’SSD compare nel BIOS o nell’UEFI, nella vista del controller del sistema operativo, nell’elenco dei dispositivi a blocchi, nella tabella delle partizioni e nel filesystem montato prima e dopo un riavvio a caldo.
La guida Linux libATA descrive come il driver attenda che un collegamento SATA diventi pronto e possa considerare assente un dispositivo quando la disponibilità non viene rilevata. Il suo modello di ripristino del collegamento SATA spiega perché un disco possa scomparire prima di raggiungere qualsiasi livello del filesystem.
Se anche il BIOS non rileva più l’SSD, concentrati sul firmware, sull’alimentazione della porta, sull’inizializzazione del collegamento, sul cavo e sul controller dell’unità. Se il BIOS lo rileva ma il sistema operativo no, conserva i log del sistema operativo e analizza l’enumerazione del driver e la modalità del controller.
Confronta riavvio a caldo, spegnimento completo e rimozione dell’alimentazione
Prova un normale riavvio, uno spegnimento del sistema operativo seguito da un’accensione immediata e uno spegnimento con alimentazione scollegata abbastanza a lungo da consentire la scarica delle linee di standby. Ripeti ogni condizione almeno due volte.
La vista dei dispositivi PCI offre un confine chiaro tra la presenza del controller e il rilevamento dello spazio di archiviazione. L’utilità lspci può confermare se il controller AHCI o SATA è cambiato durante il riavvio, anche quando il dispositivo a blocchi dell’SSD è assente.
Se solo la completa rimozione dell’alimentazione ripristina l’unità, i candidati più probabili sono uno stato persistente del controller, un ripristino incompleto del PHY SATA, uno stato del firmware dell’SSD o un’interazione con la gestione dell’alimentazione. Questo schema è meno compatibile con un normale problema di montaggio o di partizionamento.
Analizza il primo errore del collegamento SATA e del ripristino
Salva il log degli eventi del kernel o del sistema dal riavvio a caldo non riuscito prima di eseguire un avvio a freddo. Cerca messaggi di collegamento interrotto, errori COMRESET, timeout nella disponibilità del dispositivo, comandi IDENTIFY non riusciti o ripristini ripetuti della porta.
La gestione attiva del risparmio energetico del collegamento SATA può portare il collegamento in stati a basso consumo che alcune combinazioni di controller e SSD gestiscono male. ArchWiki avverte che una gestione aggressiva del risparmio energetico del collegamento può causare problemi gravi sui dispositivi incompatibili.
Il primo errore è più utile dei messaggi successivi che indicano l’indisponibilità del filesystem o del pool. Conserva il numero della porta e il modello dell’unità, in modo da poter associare ogni successivo test di cavi, alloggiamenti e firmware allo stesso percorso.
Controlla il cavo SATA, il connettore di alimentazione e i contatori degli errori dell’interfaccia
Ricollega il cavo dati SATA e il connettore di alimentazione con il server completamente spento. Controlla linguette di blocco allentate, pieghe accentuate, sdoppiatori, connettori del backplane e adattatori.
Le indicazioni per la risoluzione dei problemi di archiviazione di Unraid affermano che l’aumento degli errori CRC UDMA dovrebbe portare a controllare cavi dati, cavi di alimentazione, connessioni del controller e porte, anziché a riparare immediatamente il filesystem.
Un conteggio storico degli errori CRC non dimostra che il cavo attuale sia ancora difettoso. Registra il valore grezzo, esegui un ciclo di riavvio controllato e verifica se il contatore aumenta.
Esamina SMART, i log degli errori e lo stato del firmware dell’SSD
Acquisisci modello dell’SSD, numero di serie, revisione del firmware, numero di cicli di alimentazione, conteggio degli spegnimenti non sicuri, errori dell’interfaccia e log degli errori disponibili del dispositivo mentre l’unità è visibile.
Il riferimento smartctl descrive gli attributi SMART e i log degli errori che aiutano a distinguere i problemi di salute della memoria flash dai guasti del trasporto o del controller.
Applica un aggiornamento del firmware dell’SSD solo dopo aver verificato i backup, la compatibilità del modello e le istruzioni di ripristino del produttore. Modifica un solo livello firmware alla volta, così da poter identificare una correzione riuscita.
Usa una nuova scansione solo a scopo diagnostico
Quando il controller è ancora presente ma il disco manca, esegui una nuova scansione dello spazio di archiviazione supportata dopo aver arrestato tutte le operazioni di I/O attive. Registra se l’SSD ricompare senza un ciclo di spegnimento completo.
Microsoft documenta che il comando rescan di DiskPart individua i dischi rilevati di recente, risultando utile per distinguere un’enumerazione ritardata del sistema operativo da un’unità assente a livello del controller.
Una nuova scansione riuscita non è una soluzione permanente. Dimostra che il controller e l’SSD possono comunicare dopo un ulteriore tentativo di rilevamento; quindi, il lavoro rimanente riguarda firmware, driver, modalità del controller o inizializzazione del collegamento.
Isola l’unità, la porta e il controller prima della sostituzione
Dopo aver eseguito il backup dei dati, sposta l’SSD su una porta SATA sicuramente funzionante usando un cavo sicuramente funzionante, oppure prova un’unità sicuramente funzionante sul percorso originale. Cambia un solo componente per ciclo.
La guida ZimaSpace sulla distinzione tra guasti del cavo SATA e dell’unità fornisce il relativo flusso di isolamento per i percorsi di archiviazione soggetti a guasti intermittenti.
Il problema è risolto quando l’SSD rimane visibile attraverso riavvii a caldo ripetuti, avvii a freddo, periodi di inattività e letture prolungate senza nuovi errori del collegamento. Smetti di utilizzare l’unità per i dati principali se continua a scomparire su porte e cavi sicuramente funzionanti o segnala un peggioramento degli errori del dispositivo.
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...
