Sicurezza della cache di scrittura su unità SATA con barriere

Recentemente ho letto di scrivere cache, NCQ, bug del firmware, barriere, ecc. Riguardo alle unità SATA, e non sono sicuro di quale sia l'impostazione migliore che renderebbe sicuri i miei dati in caso di mancanza di corrente.

Da quanto ho capito, NCQ consente all'unità di riordinare le scritture per ottimizzare le prestazioni, mantenendo il kernel informato su quali richieste sono state scritte fisicamente.

Scrivere cache rende l'unità in grado di soddisfare una richiesta molto più velocemente, perché non attende che i dati vengano scritti sul disco fisico.

Non sono sicuro di come NCQ e Scrivi cache si mescolino qui ...

I filesystem, specialmente quelli con journaling, devono essere sicuri quando una particolare richiesta è stata scritta. Inoltre, il processo dello spazio utente utilizza fsync () per forzare lo svuotamento di un determinato file. Quella chiamata a fsync () non dovrebbe tornare finché il filesystem non è sicuro che i dati vengano scritti sul disco.

C'è una funzione (FUA, Force Unit Access), che ho visto solo su unità SAS, che forza l'unità a bypassare la cache e scrivere direttamente sul disco. Per tutto il resto, ci sono barriere di scrittura, che è un meccanismo fornito dal kernel che può attivare lo svuotamento della cache sull'unità. Questo costringe a scrivere tutta la cache, non solo i dati critici, rallentando così l'intero sistema se abusato, ad esempio con fsync ().

Poi ci sono unità con bug del firmware o che mentono deliberatamente su quando i dati sono stati scritti fisicamente.

Detto questo .. Esistono diversi modi per impostare i dischi / filesystem: A) NCQ e Scrivi cache disabilitata B) Solo NCQ abilitata C) Basta Scrivi cache abilitata D) Sia NCQ che Scrivi cache abilitata

Suppongo che le barriere siano abilitate. A proposito, come verificare se sono effettivamente abilitate?

In caso di interruzione dell'alimentazione, mentre scrivo attivamente sul disco, la mia ipotesi è che l'opzione B (NCQ, nessuna cache) sia sicura, sia per il journal del filesystem che per i dati. Potrebbe esserci una penalità per le prestazioni.

L'opzione D (NCQ + cache), se si usano barriere o FUA, sarebbe sicura per il journal del filesystem e le applicazioni che usano fsync (). Sarebbe un male per i dati che stavano aspettando nella cache, e spetterà al filesystem rilevarli (checksum), e almeno il filesystem non sarà (si spera) in uno stato instabile. Per quanto riguarda le prestazioni, dovrebbe essere migliore.

La mia domanda, tuttavia, rimane ... Mi sto perdendo qualcosa? C'è qualche altra variabile da prendere in considerazione? Esiste uno strumento in grado di confermarlo e che le mie unità si comportano come dovrebbero?

Per i sistemi Enterprise diretti, esiste un livello aggiuntivo sotto forma di adattatore di archiviazione (quasi sempre una scheda RAID) su cui esiste ancora un altro livello di cache. C'è un sacco di astrazione nella memoria pila in questi giorni, e sono andato in una profonda dettaglio in questo in una serie di blog che ho fatto sul conoscere il vostro I / O .

Le schede RAID possono bypassare la cache su disco, alcune delle quali consentono anche di attivare questa funzione nel BIOS RAID. Questo è uno dei motivi per cui i dischi Enterprise sono Enterprise, il loro firmware consente cose che le unità consumer (in particolare le unità "verdi") non fanno. Questa funzione risolve direttamente il caso di cui ti preoccupi: mancanza di corrente con scritture senza impegno. La cache della scheda RAID, che dovrebbe essere di tipo batteria o con supporto flash, verrà conservata fino al ripristino dell'alimentazione e la scrittura di tali scritture.

Alcuni SSD aziendali includono un condensatore integrato con abbastanza grinta per impegnare la cache integrata prima di spegnersi completamente.

Se stai lavorando con un sistema con dischi direttamente collegati alla scheda madre, ci sono meno garanzie. A meno che i dischi stessi non abbiano la capacità di eseguire il commit della cache di scrittura, un errore di alimentazione causerà effettivamente una perdita. Il filesystem xfs ha guadagnato una reputazione per inaffidabilità a causa della sua incapacità di sopravvivere proprio in questa modalità di errore; è stato progettato per funzionare su sistemi aziendali completi con una capacità di sopravvivenza dello storage progettata.

Tuttavia, il tempo è passato e XFS è stato progettato per sopravvivere. Gli altri principali filesystem Linux (così come ntfs su Windows) avevano già l' ingegneria per sopravvivere a questa modalità molto fallita. Il modo in cui dovrebbe funzionare è che le scritture perse non verranno visualizzate nel diario FS e sapranno che non sono state commesse, quindi la corruzione verrà rilevata e risolta in modo sicuro.

Indichi qui un problema: il firmware del disco che si trova. In questo caso il diario di bordo ha fatto un'ipotesi sbagliata rispetto alla realtà e la corruzione potrebbe non essere rilevata per qualche tempo. Parity RAID e mirror RAID possono aggirare il problema poiché dovrebbe esserci un'altra copia di cui eseguire il pull. Ma le configurazioni a disco singolo non avranno quel controllo incrociato, quindi in realtà si verificheranno errori.

Si aggira il rischio del firmware utilizzando unità di livello Enterprise che ottengono molta più convalida (e vengono testate rispetto ai modelli di carico di lavoro presunti) e progettando il sistema di archiviazione in modo che possa sopravvivere a tali falsità.

Il journal del filesystem inizialmente attendeva che la scrittura sul journal fosse completata prima di inviare la scrittura ai metadati, supponendo che non ci fosse cache di scrittura sull'unità. Con la cache di scrittura dell'unità abilitata, questo presupposto è rotto e può causare la perdita di dati. Pertanto, sono state create barriere. Con le barriere, il journal può assicurarsi che la scrittura sul journal sia completata prima della scrittura nei metadati, anche se il disco utilizza la cache in scrittura. A livello del driver del disco, la barriera impone lo svuotamento della cache del disco prima che venga inviato il successivo IO, quando l'unità segnala che ha una cache di scrittura ed è abilitata. Altrimenti, ciò non è necessario, quindi la barriera impedisce solo l'emissione dell'IO successivo all'azionamento fino al completamento dell'IO precedente. NCQ significa solo che potrebbe essere necessario attendere il completamento di più di una richiesta in sospeso prima di emetterne altre.