Errori silenziosi del disco e affidabilità dello scambio di Linux

La mia comprensione è che i dischi rigidi e gli SSD implementano alcune correzioni di errori di base all'interno dell'unità e che la maggior parte delle configurazioni RAID, ad esempio mdadm, dipenderà da ciò per decidere quando un'unità non è riuscita a correggere un errore e deve essere messa offline. Tuttavia, ciò dipende dal fatto che la memoria sia accurata al 100% nella sua diagnosi di errore. Non è così, e una configurazione comune come un mirror RAID-1 a due unità sarà vulnerabile: supponiamo che alcuni bit su un'unità siano silenziosamente danneggiati e l'unità non segnali un errore di lettura. Pertanto, i file system come btrfs e ZFS implementano i propri checksum, in modo da non fidarsi dei firmware delle unità buggy, dei cavi SATA glitch e così via.

Allo stesso modo, la RAM può anche avere problemi di affidabilità e quindi abbiamo RAM ECC per risolvere questo problema.

La mia domanda è questa : qual è il modo canonico per proteggere il file di scambio di Linux da corruzione silenziosa / decomposizione dei bit non catturati dal firmware dell'unità su una configurazione a due dischi (cioè usando i driver del kernel mainline)? Mi sembra che una configurazione che manca di protezione end-to-end qui (come quella fornita da btrfs) in qualche modo nega la tranquillità offerta dalla RAM ECC. Eppure non riesco a pensare a un buon modo:

• btrfs non supporta affatto gli swapfile. È possibile impostare un dispositivo loop da un file btrfs e scambiarlo. Ma questo ha problemi:
  • Le scritture casuali non funzionano bene: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • Il suggerimento di disabilitare il copy-on-write disabiliterà anche il checksum, sconfiggendo così l'intero punto di questo esercizio. Il loro presupposto è che il file di dati abbia le proprie protezioni interne.
• ZFS su Linux consente di utilizzare uno ZVOL come swap, che immagino possa funzionare: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - tuttavia, dalla mia lettura, ZFS è normalmente impegnativo in memoria e farlo funzionare in uno scambio -solo applicazione sembra un po 'di lavoro per capirlo. Penso che questa non sia la mia prima scelta. Perché dovresti usare un modulo kernel out-of-tree solo per avere uno scambio affidabile è al di là di me - sicuramente c'è un modo per farlo con la maggior parte delle moderne distribuzioni / kernel Linux in questo giorno ed età?
• In realtà c'era un thread su una mailing list del kernel Linux con patch per abilitare i checksum all'interno del gestore della memoria stesso, per le ragioni esatte che discuto in questa domanda: http://thread.gmane.org/gmane.linux.kernel/989246 - purtroppo, per quanto ne so, la patch è morta e non è mai arrivata a monte per motivi a me sconosciuti. Peccato, sembrava una bella caratteristica. D'altra parte, se si inserisce lo swap su un RAID-1 - se la corruzione è al di là della capacità del checksum di riparare, si vorrebbe che il gestore della memoria provasse a leggere dall'altra unità prima di andare nel panico o altro, che è probabilmente al di fuori dell'ambito di ciò che dovrebbe fare un gestore della memoria.

In sintesi:

• RAM ha ECC per correggere gli errori
• I file in memoria permanente hanno btrfs per correggere errori
• Lo scambio ha ??? <--- questa è la mia domanda

Confidiamo nell'integrità dei dati recuperati dallo swap perché l' hardware di archiviazione ha checksum, CRC e simili.

In uno dei commenti sopra, dici:

vero, ma non proteggerà da salti di bit esterni al disco stesso

"It" significa qui i checksum del disco.

Questo è vero, ma SATA utilizza CRC a 32 bit per comandi e dati. Pertanto, hai una possibilità su 1 miliardo di miliardi di danneggiare i dati in modo non rilevabile tra il disco e il controller SATA. Ciò significa che una fonte di errore continua potrebbe introdurre un errore ogni volta che viene trasferito ogni 125 MiB, ma una fonte di errore casuale, rara come i raggi cosmici, causerebbe errori non rilevabili a una velocità evanescente.

Tieni anche conto che se hai una fonte che causa un errore non rilevato a una velocità vicina a una per 125 MiB trasferiti, le prestazioni saranno terribili a causa dell'elevato numero di errori rilevati che richiedono un nuovo trasferimento. Il monitoraggio e la registrazione ti avviseranno probabilmente del problema in tempo per evitare la corruzione non rilevata.

Per quanto riguarda i checksum del supporto di memorizzazione, ogni disco SATA (e prima di esso, PATA) utilizza checksum per settore di qualche tipo. Una delle caratteristiche dei dischi rigidi "enterprise" sono i settori più grandi protetti da funzionalità aggiuntive di integrità dei dati , che riducono notevolmente la possibilità di un errore non rilevato.

Senza tali misure, non sarebbe utile il pool di settori di riserva in ogni disco rigido: l'unità stessa non è in grado di rilevare un settore danneggiato, quindi non può mai scambiare nuovi settori.

In un altro commento, chiedi:

se SATA è così affidabile, perché esistono file system con checksum come ZFS, btrfs, ReFS?

In generale, non chiediamo a swap di archiviare dati a lungo termine. Il limite per l'archiviazione di swap è il tempo di attività del sistema e la maggior parte dei dati in swap non dura così a lungo, poiché la maggior parte dei dati che attraversano il sistema di memoria virtuale del sistema appartiene a processi di durata molto più breve.

Inoltre, i tempi di attività si sono generalmente ridotti nel corso degli anni, con l'aumentare della frequenza di kernel e libcaggiornamenti, virtualizzazione, architetture cloud, ecc.

Inoltre, la maggior parte dei dati in swap è intrinsecamente inutilizzata in un sistema ben gestito, essendo uno che non si esaurisce dalla RAM principale. In un tale sistema, le uniche cose che finiscono con lo scambio sono le pagine che il programma non usa spesso, se mai. Questo è più comune di quanto si possa immaginare. La maggior parte delle librerie dinamiche a cui i tuoi programmi collegano contengono routine che il tuo programma non utilizza, ma dovevano essere caricate nella RAM dal linker dinamico . Quando il sistema operativo vede che non si utilizza tutto il testo del programma nella libreria, scambia fuori, facendo spazio per codice e dati che i programmi stanno utilizzando. Se tali pagine di memoria scambiate fossero corrotte, chi lo saprebbe mai?

Contrastalo con quelli come ZFS in cui prevediamo che i dati vengano archiviati in modo duraturo e persistente, in modo che duri non solo oltre il tempo di attività corrente del sistema, ma anche oltre la durata dei singoli dispositivi di archiviazione che compongono il sistema di archiviazione. ZFS e simili stanno risolvendo un problema con una scala temporale di circa due ordini di grandezza più lunga del problema risolto dallo scambio. Pertanto, abbiamo requisiti di rilevamento della corruzione molto più elevati per ZFS rispetto a Linux swap.

ZFS e simili differiscono dallo swap in un altro modo chiave qui: non scambiamo RAID filesystem insieme. Quando più dispositivi di swap sono in uso su un singolo computer, si tratta di uno schema JBOD , non come RAID-0 o superiore. (ad es. schema di file di scambio concatenato di macOS , Linux swapon, ecc.) Dato che i dispositivi di scambio sono indipendenti, piuttosto che interdipendenti come con RAID, non abbiamo bisogno di estesi checksum perché la sostituzione di un dispositivo di scambio non implica la ricerca di altri dispositivi di scambio interdipendenti per i dati che dovrebbero andare sul dispositivo sostitutivo. In termini ZFS, non ripristiniamo i dispositivi di scambio da copie ridondanti su altri dispositivi di archiviazione.

Tutto ciò significa che è necessario utilizzare un dispositivo di scambio affidabile. Una volta ho usato un contenitore HDD USB esterno da $ 20 per salvare un pool ZFS in difficoltà, solo per scoprire che il contenitore era esso stesso inaffidabile, introducendo errori propri nel processo. Il forte checksum di ZFS mi ha salvato qui. Non è possibile cavarsela con un trattamento così sprezzante dei supporti di archiviazione con un file di scambio. Se il dispositivo di scambio sta morendo e si sta avvicinando al caso peggiore in cui potrebbe iniettare un errore non rilevabile ogni 125 MiB trasferiti, è sufficiente sostituirlo, APPENA POSSIBILE.

Il senso generale della paranoia in questa domanda si trasforma in un'istanza del problema dei generali bizantini . Continua a leggere, medita sulla data del 1982 sul documento accademico che descrive il problema nel mondo dell'informatica e poi decidi se, nel 2019, hai nuovi pensieri da aggiungere a questo problema. E se no, allora forse userete solo la tecnologia progettata da tre decenni di laureati CS che conoscono tutti il ​​problema dei generali bizantini.

Questo è terreno ben calpestato. Probabilmente non puoi trovare un'idea, un'obiezione o una soluzione che non sia già stata discussa a morte nelle riviste di informatica.

SATA non è certamente del tutto affidabile, ma a meno che non ti unirai al mondo accademico o ad uno dei team di sviluppo del kernel, non sarai in grado di aggiungere materialmente allo stato dell'arte qui. Questi problemi sono già ben gestiti, come hai già notato: ZFS, btrfs, ReFS ... Come utente del sistema operativo, devi semplicemente fidarti che i creatori del sistema operativo si stanno occupando di questi problemi per te, perché sanno anche sui generali bizantini.

Al momento non è pratico mettere il tuo file di swap in cima a ZFS o Btrfs, ma se quanto sopra non ti rassicura, potresti almeno metterlo in cima a xfs o ext4. Sarebbe meglio che usare una partizione di swap dedicata.

dm-integrità

Vedi: Documentazione / device-mapper / dm-integral.txt

dm-integritysarebbe normalmente utilizzato in modalità journaling. In caso di swap, potresti organizzare di fare a meno del journaling. Ciò potrebbe ridurre significativamente il sovraccarico di prestazioni. Non sono sicuro se sarebbe necessario riformattare la partizione di scambio per integrità su ogni avvio, per evitare errori dopo un arresto impuro.

Nell'annuncio iniziale didm-integrity , l'autore afferma invece una preferenza per "protezione dell'integrità dei dati di livello superiore". Nel caso di swap, ciò aprirebbe la possibilità di memorizzare i checksum nella RAM. Tuttavia, tale opzione richiederebbe entrambe modifiche non banali al codice di scambio corrente e aumenterebbe l'utilizzo della memoria. (Le attuali tracce di codice si scambiano in modo efficiente usando le estensioni, non singole pagine / settori).

DIF / DIX?

Il supporto DIX è stato aggiunto da Oracle in Linux 2.6.27 (2008).

L'uso di DIX fornisce integrità end-to-end?

Puoi consultare il tuo fornitore. Non so come si possa dire se mentono al riguardo.

DIX è necessario per proteggere i dati in volo tra il sistema operativo (sistema operativo) e l' HBA .

DIF da solo aumenta la protezione dei dati in volo tra l'HBA e il dispositivo di archiviazione . (Vedi anche: presentazione con alcune cifre sulla differenza nei tassi di errore ).

Proprio perché il checksum nel campo di guardia è standardizzato, è tecnicamente possibile implementare i comandi DIX senza fornire alcuna protezione per i dati inattivi. Chiedi all'HBA (o al dispositivo di archiviazione) di rigenerare il checksum al momento della lettura. Questa prospettiva è stata resa abbastanza chiara dal progetto DIX originale.

• DIF / DIX sono checksum dei blocchi logici ortogonali
  • Ti amiamo ancora, btrfs!
  • Gli errori di checksum del blocco logico vengono utilizzati per il rilevamento di dati danneggiati
  • Il rilevamento avviene al momento della LETTURA
  • ... che potrebbe essere mesi dopo, il buffer originale viene perso
  • Eventuali copie ridondanti possono anche essere dannose se il buffer originale è stato confuso
• DIF / DIX riguardano la prevenzione proattiva della corruzione
  • In primo luogo, impedire che i dati errati vengano archiviati sul disco
  • ... e scoprire i problemi prima che il buffer originale venga cancellato dalla memoria

- lpc08-data-integral.pdf da oss.oracle.com

Una delle loro prime pubblicazioni su DIX menziona la possibilità di utilizzare DIX tra sistema operativo e HBA anche quando l'unità non supporta DIF.

La mendacità completa è relativamente improbabile in contesti "enterprise" in cui DIX è attualmente utilizzato; la gente lo noterebbe. Inoltre, DIF era basato su hardware esistente che poteva essere formattato con settori a 520 byte. Il protocollo per l'utilizzo di DIF presumibilmente richiede di riformattare prima l'unità, vedere ad esempio il sg_formatcomando.

Ciò che è più probabile è un'implementazione che non segue il vero principio end-to-end . Per fare un esempio, viene menzionato un fornitore che supporta un'opzione di checksum più debole per DIX per salvare i cicli della CPU, che viene quindi sostituita da un checksum più forte più in basso nello stack. Questo è utile, ma non è una protezione completa end-to-end.

In alternativa, un sistema operativo potrebbe generare i propri checksum e memorizzarli nello spazio dei tag dell'applicazione. Comunque non c'è supporto per questo nell'attuale Linux (v4.20) . Il commento, scritto nel 2014, suggerisce che ciò potrebbe essere dovuto al fatto che "pochissimi dispositivi di archiviazione consentono effettivamente di utilizzare lo spazio tag dell'applicazione". (Non sono sicuro se ciò si riferisca al dispositivo di archiviazione stesso, all'HBA o ad entrambi).

Che tipo di dispositivi DIX sono disponibili che funzionano con Linux?

La separazione dei buffer dei metadati dei dati e dell'integrità, nonché la scelta nei checksum, è indicata come Data Integrity Extensions [DIX]. Poiché queste estensioni non rientrano nell'ambito di applicazione degli organismi di protocollo (T10, T13), Oracle e i suoi partner stanno provando a standardizzarle all'interno della Storage Networking Industry Association.

- v4.20 / Documentation / block / data-integral.txt

Wikipedia mi dice che DIF è standardizzato in NVMe 1.2.1. Per gli HBA SCSI, sembra un po 'difficile stabilire se non abbiamo uno standard a cui puntare. Al momento potrebbe essere più preciso parlare del supporto "Linux DIX" :-). Sono disponibili dispositivi:

SCSI T10 DIF / DIX [sic] è pienamente supportato in Red Hat Enterprise Linux 7.4, a condizione che il fornitore dell'hardware lo abbia qualificato e fornisca pieno supporto per la particolare configurazione di HBA e array di archiviazione. DIF / DIX non è supportato su altre configurazioni, non è supportato per l'uso sul dispositivo di avvio e non è supportato su guest virtualizzati.

Al momento, è noto che i seguenti fornitori forniscano questo supporto ...

- Note di rilascio di RHEL 7.5, capitolo 16. Conservazione

Tutto l'hardware menzionato nelle note di rilascio di RHEL 7.5 è Fibre Channel.

Non conosco questo mercato. Sembra che DIX potrebbe diventare più ampiamente disponibile nei server in futuro. Non conosco alcun motivo per cui sarebbe disponibile per i dischi SATA consumer - per quanto ne so non esiste nemmeno uno standard di fatto per il formato del comando. Sarò interessato a vedere se sarà disponibile in modo più ampio su NVMe.

Lo scambio ha ??? <--- questa è la mia domanda

Swap non è ancora protetto in Linux (ma vedi UPD).

Bene, ovviamente c'è ZFS su Linux che è in grado di essere un archivio di scambio ma c'è ancora un blocco in alcune circostanze - revocando così efficacemente questa opzione.

Btrfs non riesce ancora a gestire i file di scambio . Citano il possibile uso del loopback sebbene sia notoriamente di scarso rendimento. C'è un'indicazione poco chiara che Linux 5 potrebbe averlo finalmente (?) ...

Le patch per proteggere lo swap convenzionale stesso con checksum non sono diventate mainstream.

Quindi, tutto sommato: no. Linux ha ancora un vuoto lì.

UPD. : Come sottolinea @ sourcejedi , esiste uno strumento come dm-integral. Il kernel Linux dalla versione 4.12 ha ottenuto il target del device-mapper che può essere utilizzato per fornire checksum a qualsiasi dispositivo a blocchi generale e quelli che sono per lo scambio non fanno eccezione. Gli strumenti non sono ampiamente integrati nelle principali distro e la maggior parte di essi non ha alcun supporto nel sottosistema udev, ma alla fine questo dovrebbe cambiare. Se accoppiato con un provider di ridondanza, diciamo messo su una parte superiore di MD aka Linux Software RAID, dovrebbe essere possibile non solo rilevare il bit rot ma anche reindirizzare la richiesta I / O a dati integri perché dm-integrità indicherebbe che c'è un problema e MD dovrebbe gestirlo.

Non penso che esista un modo "canonico", quindi la mia opinione personale è la seguente.

Avendo monitorato l'avanzamento di btrfs dal punto di vista di un potenziale utente, devo dire che è ancora in qualche modo oscuro per me. Ci sono funzionalità che sono mature e pronte per l'uso in produzione e ci sono caratteristiche che sono apparentemente immature e pericolose da usare.

Personalmente, non ho il tempo di decidere quale funzione utilizzare e quali no, lasciando perdere il tempo che avrei bisogno di capire come disattivare o attivare queste funzionalità.

Al contrario, ZFS è solido e maturo (IMHO). Quindi, per rispondere alla tua domanda, userei ZFS (a proposito, non consuma molta memoria - vedi sotto).

Ma per te, btrfs potrebbe essere la scelta giusta poiché lo stai già utilizzando (se ti ho fatto bene), e uno dei commenti sopra mostra come usarlo per lo scambio.

Per puro caso, negli ultimi giorni ho messo alcuni server Linux su ZFS, ogni volta incluso il file system root e lo swap. Prima di farlo, ho svolto alcune ricerche approfondite, che mi hanno richiesto diversi giorni. Un breve riassunto di ciò che ho imparato:

Il consumo di memoria di ZFS

C'è un malinteso comune riguardo al consumo di memoria di ZFS. ZFS generalmente non consuma molta memoria; infatti, funziona con TB di spazio di archiviazione su macchine con 2 GB di RAM. Solo se usi la deduplicazione (disattivata per impostazione predefinita), ha bisogno di molta e molta RAM.

Rilevamento / correzione errori hardware

Se i meccanismi SATA, PATA, RAID o altri meccanismi di rilevamento / correzione degli errori sono sufficienti per l'integrità dei dati è un argomento che provoca discussioni infinite e persino guerre di fiamma in tutti i luoghi della rete. In teoria, un dispositivo di archiviazione hardware dovrebbe segnalare (e possibilmente correggere) qualsiasi errore riscontrato e anche l'hardware di trasmissione dei dati a tutti i livelli (chipset, memoria, ecc.).

Bene, non lo fanno in tutti i casi o reagiscono in modo sorprendente agli errori. Ad esempio, prendiamo una tipica configurazione RAID5. Normalmente, se un disco ha un problema, lo riporterà al RAID che a sua volta costruisce i dati da leggere dagli altri dischi e li trasmette, ma lo riscrive anche sul disco difettoso (che a sua volta probabilmente rimappa il settore prima di scrivere i dati); se lo stesso disco riporta troppi errori, il RAID lo porta offline e informa l'amministratore (se configurato correttamente).

Fin qui tutto bene, ma ci sono casi in cui i dati difettosi escono da un disco senza che il disco riporti un errore (vedere la sezione successiva). La maggior parte dei RAID è in grado di rilevare questa situazione utilizzando le informazioni di parità, ma la loro reazione è stupida: invece di segnalare l'errore e impedire che i dati vengano trasmessi, ricalcoleranno la parità in base ai dati errati e scriveranno la nuova parità nei rispettivi disco, contrassegnando così i dati difettosi come sempre corretti.

È un comportamento ragionevole? Per quanto ne so, la maggior parte dei controller RAID5 hardware e persino il RAID md di Linux funzionano in questo modo.

Non conosco la correzione degli errori di btrfs, ma alla fine dovresti leggere di nuovo attentamente i documenti, in particolare se stai usando il RAID di btrfs.

Marciume silenzioso

Nonostante tutte le guerre di fiamma e (pseudo-) discussioni scientifiche: la realtà è per lo più diversa dalla teoria e il bit bit silenzioso si verifica sicuramente anche se la teoria potrebbe affermare il contrario (il silenzio del bot silenzioso di solito significa che i dati sull'archiviazione hardware vengono danneggiati senza che il dispositivo di archiviazione riporti un errore durante la lettura di questi dati, ma aggiungerò i bit lancianti in qualsiasi punto del percorso di trasmissione a questa definizione).

Che ciò accada non è una mia opinione personale: almeno Google, Amazon e CERN hanno pubblicato white paper dettagliati che trattano esattamente questo argomento. I documenti sono disponibili pubblicamente per il download gratuito. Hanno fatto esperimenti sistematici con diversi milioni di dischi rigidi e centinaia di migliaia di server / dispositivi di archiviazione, sia perché avevano problemi con il danneggiamento dei dati non rilevato o perché volevano sapere cosa fare per impedirlo prima che accadesse.

In sintesi, i dati nelle loro server farm erano stati danneggiati con un tasso significativamente superiore rispetto alle statistiche MTBF o ad altre teorie che ci si aspetterebbe. Per significativamente più alto, intendo ordini di grandezza.

Quindi il bit rot silenzioso, ovvero la corruzione dei dati non rilevati in qualsiasi punto del percorso di trasmissione, è un vero problema di vita.

Durata dei dati

Warren Young ha ragione quando afferma che i dati di scambio hanno una durata breve. Ma vorrei aggiungere la seguente considerazione: non solo i dati (nel senso dei documenti) vengono scambiati, ma (forse anche più probabilmente) parti dell'O / S o altri software in esecuzione . Se avessi un MP3 in scambio, potrei vivere con un tocco lanciante. Se (a causa di una situazione estrema) parti del mio software server httpd di produzione sono in scambio, non posso assolutamente vivere con un bit lanciante che in seguito porta all'esecuzione di codice corrotto se non rilevato.

Epilogo

Per me, ZFS risolve questi problemi o, più precisamente, li allontana dai dischi in memoria e quindi riduce la probabilità di marcire bit silenzioso di alcuni ordini di grandezza. Inoltre, se configurato correttamente (ovvero mirroring anziché RAID), fornisce una correzione dell'errore pulita e ragionevole che funziona come previsto e può essere compresa facilmente dopo tutto.

Detto questo, tieni presente che non otterrai mai la sicurezza assoluta. Personalmente, mi fido della mia RAM ECC più dei miei dischi e sono convinto che ZFS con i suoi checksum end-to-end riduce la probabilità di problemi per ordini di grandezza. Non consiglierei mai di usare ZFS senza RAM ECC, però.

Disclaimer: non sono in alcun modo associato a nessun fornitore o sviluppatore ZFS. Questo è vero per tutte le varianti (forcelle) di ZFS. Ne sono appena diventato fan nei giorni scorsi ...