Ho creato un RAID software, ho riavviato, e lo storage non c'è: l'array non viene assemblato all'avvio

Hai unito i dischi, l'array è salito, lo storage è comparso, ci hai scritto dei dati. Tutto ha funzionato.

Poi hai riavviato la macchina e lo storage non c'è più.

I dischi stanno bene. I dati sono ancora lì. A mancare è un'altra cosa.

Un array non sta sui dischi, sta nell'istruzione di assemblaggio

Mostrare più dischi come un unico storage non è una proprietà che risieda sui dischi. A ogni avvio il sistema deve ritrovare quei dischi e rimetterli insieme.

C'è una registrazione che gli dice come. Senza quella registrazione l'array potrebbe non essere assemblato. E anche se lo fosse, potrebbe risalire con un nome diverso, il che porta allo stesso punto: il tuo storage punta al nome vecchio e lì non c'è nulla.

Quindi il problema non è "i dati sono persi", è "la strada verso i dati non è stata costruita all'avvio". Suona meno spaventoso, ma nell'attimo di panico le due cose danno la stessa sensazione.

La posizione di Proxmox stesso

Va detto con onestà: la via integrata e supportata su Proxmox è ZFS. Chiedi un mirror dei dischi durante l'installazione e ottieni quello.

Il RAID software classico funziona, ma non è la via che l'installatore predispone per te. Il che significa che, se lo scegli, assicurarsi che i passi di assemblaggio all'avvio siano stati fatti bene tocca a te.

Restano casi in cui ha senso: hai già un array e lo stai migrando, la disposizione del tuo controller non è quella che ZFS si aspetta, oppure la memoria della macchina è stretta per ZFS. Sono ragioni vere. Sceglierlo senza una ragione significa procurarsi lavoro per dopo.

La regola: un array che non ha visto un riavvio non conta come array

È la frase più pratica di questo articolo.

Dopo aver creato l'array, riavvia apposta una volta, finché niente dipende da lui. Lo storage torna? Torna con lo stesso nome? Il contenuto si vede?

La stessa cosa l'abbiamo scritta nell'articolo sugli avvisi di questa wiki: un allarme non provato non è un meccanismo, è una speranza. Per un array vale uguale. Un array che non è sopravvissuto a un riavvio è un array che tu credi funzioni.

La trappola del cambio di nome

Seconda trappola frequente: l'array viene assemblato, ma con un nome diverso da quello della volta prima.

La tua definizione di storage punta al nome vecchio, quindi lo storage è di nuovo invisibile. Stavolta l'array è in piedi, ma nessuno lo sta guardando.

La soluzione è agganciare lo storage per identità invece che per nome. I nomi possono cambiare, le identità no.

Cosa fa Atlas

Quando Atlas crea un array scrive anche la registrazione di avvio, e mostra a schermo questo avviso: se questo passo fallisce, l'array potrebbe non essere assemblato all'avvio e lo storage diventa invisibile.

L'avviso era vero. Ma per un periodo si smentiva da solo.

Per produrre la registrazione veniva chiamato lo strumento di sistema. È stato misurato, ed è emerso questo: quando non c'è alcun array, quello strumento esce con codice zero e non stampa nulla. Cioè dice "riuscito" e non ti consegna niente.

Risultato: non veniva scritto nulla, ma il passo veniva registrato come riuscito. Proprio quello che l'avviso aveva appena descritto stava capitando all'utente, mentre lo schermo mostrava tutto a posto.

La correzione aveva due parti. Il formato atteso è stato determinato misurando e non indovinando, e se l'output non corrisponde a quel formato il passo conta come fallito. Anche un output vuoto è un fallimento. E per non scrivere due volte lo stesso array, si controllano sia il percorso del dispositivo sia l'identità.

La lezione generale

La frase che conta qui è questa: "il comando è riuscito" e "il lavoro è stato fatto" non sono la stessa cosa.

Un codice di uscita ti dice se lo strumento è stato eseguito. Non ti dice se il risultato si è prodotto. Se l'intero scopo di un passo è produrre un effetto, la cosa da controllare non è lo stato dello strumento ma l'effetto stesso.

In questa wiki ci sono altri due articoli della stessa famiglia. In quello sui dischi orfani si è separata una risposta vuota dal non aver ottenuto risposta. In quello sul nome del server c'era il pericolo di mettere un valore predefinito dall'aria plausibile al posto dell'ignoto. Questo è il terzo: mettere un codice di uscita al posto di un risultato mai accertato.

Tutti e tre sono facce dello stesso guasto: il programma afferma qualcosa che non ha verificato.