Perché gli errori di scrub del NAS seguono una porta del controller tra unità diverse?
Gli errori di scrub che seguono una porta del controller su unità diverse indicano generalmente il percorso condiviso, non il supporto di registrazione dei dischi.
Uno scrub legge un insieme ampio di blocchi e può rilevare guasti che il normale accesso quotidiano non raggiunge mai. Se unità note per essere integre sviluppano errori solo quando sono collegate tramite la stessa porta, tra i componenti comuni possono esserci il canale del controller, il connettore, il cavo, la linea del backplane, il percorso dell’expander, il percorso di alimentazione, il firmware e il raffreddamento attorno a quel percorso. La diagnosi deve dimostrare che l’errore segue la porta, preservando al contempo l’identità dell’unità, i timestamp e il tipo di errore.
Confermare che l’errore segua la porta, non il nome dell’unità
Registrare i numeri di serie delle unità, gli ID dispositivo stabili, la porta del controller o il PHY dell’HBA, il cavo, l’alloggiamento, il membro del pool e i contatori di lettura, scrittura e checksum prima del prossimo scrub. Non fare affidamento solo sui nomi variabili /dev/sdX.
Il flusso di risoluzione dei problemi delle unità di TrueNAS sottolinea l’importanza di raccogliere le informazioni sul pool e i dati SMART prima di cancellare gli errori o sostituire un dispositivo.
Dopo uno scambio a sistema spento, verificare se l’errore segue l’unità, l’alloggiamento, il cavo o la porta del controller. Cambiare un solo componente per test, così il risultato resta interpretabile.
Distinguere gli errori di checksum dello scrub dagli errori di lettura e scrittura dell’unità
Salvare il risultato completo dello scrub e i contatori per dispositivo. Un’inesattezza del checksum, un timeout del comando, un settore illeggibile e una scrittura non riuscita rappresentano livelli di guasto diversi.
Oracle documenta che uno scrub ZFS verifica i checksum dei dati attivi, mentre lo stato del pool segnala separatamente gli errori di lettura, scrittura e checksum per ogni dispositivo.
Se gli errori di checksum aumentano senza errori del supporto e seguono un unico percorso fisico, sospettare una corruzione dei dati tra la memoria e l’unità o un trasporto instabile. Se gli errori di lettura seguono l’unità tra porte diverse, è più probabile che la causa sia il disco.
Mappare il disco sul controller e sul collegamento esatti
Tracciare il percorso stabile del disco attraverso il controller host, l’indirizzo PCI, l’expander SAS o la porta SATA, l’enclosure, il cavo e l’alloggiamento. Salvare la mappatura prima di spostare l’hardware.
La vista dei dispositivi lspci identifica il controller di archiviazione PCI indipendentemente dai nomi del filesystem e del pool, aiutando a distinguere un percorso del controller guasto da un disco a cui è stato semplicemente assegnato un nuovo nome dispositivo.
Per un HBA, includere le informazioni sul PHY e sull’expander quando disponibili. Due alloggiamenti anteriori possono condividere un cavo mini-SAS o una linea dell’expander anche se l’interfaccia li presenta come slot separati.
Controllare i reset del collegamento SATA o SAS durante lo scrub
Monitorare il log del kernel dal momento in cui inizia lo scrub. Cercare reset forzati, errori COMRESET, eventi di perdita del collegamento, timeout dei comandi, errori di protocollo e variazioni della velocità negoziata sul percorso interessato.
La guida Linux libATA descrive il ripristino del collegamento e dagli errori per porta, mostrando perché i messaggi ripetuti associati a una sola porta ATA costituiscono una prova più forte rispetto a un avviso generico del pool.
Conservare il primo messaggio relativo al trasporto. Gli errori successivi del filesystem potrebbero essere solo conseguenze della perdita di comunicazione tra il controller e l’unità durante una lettura.
Confrontare i contatori CRC dell’interfaccia e dei timeout dei comandi
Acquisire gli attributi e i log SMART di ogni unità prima e dopo uno scrub. Verificare se i contatori CRC dell’interfaccia o dei timeout dei comandi aumentano solo sul percorso interessato.
Unraid spiega che gli errori CRC UDMA si verificano tra l’unità e il controller, coinvolgendo spesso cavi, connettori, instradamento o collegamento del controller, piuttosto che danni ai piatti.
I totali CRC storici non identificano il componente attualmente responsabile. Registrare il conteggio grezzo, eseguire un test delimitato e verificare solo se il valore è aumentato.
Eseguire i test dell’unità separatamente dal carico di lavoro dello scrub
Eseguire i test SMART brevi ed estesi supportati quando il pool è altrimenti inattivo e i dati sono protetti. Evitare di pianificare un test SMART completo contemporaneamente a un altro scrub o a una ricostruzione.
Il riferimento smartctl di Debian distingue i test automatici interni dell’unità e i log degli errori dalla verifica del filesystem eseguita dal sistema host.
Un’unità che supera un test interno ma produce errori solo su una porta del controller rafforza l’ipotesi di un problema nel percorso. Non dimostra che il disco sia perfetto, quindi continuare a monitorarlo dopo aver cambiato porta.
Sostituire un solo componente condiviso e ripetere uno scrub delimitato
Con i backup aggiornati e il server spento, spostare un’unità sicuramente integra attraverso il percorso sospetto oppure sostituire un solo cavo, mantenendo stabili le altre variabili. Non scambiare tutti i dischi contemporaneamente.
La guida ZimaSpace su disco RAID espulso rispetto a un alloggiamento difettoso fornisce il metodo di scambio controllato correlato; questo articolo applica quella logica nello specifico agli errori di scrub che seguono ripetutamente una porta del controller.
Interrompere lo scrub e dare priorità alla protezione dei dati se gli errori aumentano rapidamente, più unità sullo stesso controller vengono reimpostate, il pool si degrada o le applicazioni segnalano file danneggiati. Il problema è risolto solo dopo che lo stesso percorso della porta ha completato più scrub e normali operazioni di I/O senza nuovi errori.
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...
