Confidiamo nell'integrità dei dati recuperati dallo scambio a causa dell'hardware di archiviazione ha checksum, CRC e così via.
In uno dei commenti sopra, dici:
true, ma non proteggerà dai bit flip al di fuori del 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 4 miliardi di corrompere 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 125 MiB trasferiti, ma una fonte di errore rara e casuale come i raggi cosmici causerebbe errori non rilevabili a una velocità incredibilmente bassa.
Tieni anche presente che se disponi di una sorgente che causa un errore non rilevato a un tasso vicino a uno ogni 125 MiB trasferiti, le prestazioni saranno terribili a causa dell'elevato numero di rilevati errori che richiedono il ritrasferimento. Il monitoraggio e la registrazione probabilmente ti avviseranno del problema in tempo per evitare la corruzione non rilevata.
Per quanto riguarda i checksum del supporto di archiviazione, ogni disco SATA (e prima di esso, PATA) utilizza checksum per settore di qualche tipo. Una delle caratteristiche caratteristiche dei dischi rigidi "enterprise" è costituita da 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 avrebbe senso il pool di settori di riserva in ogni disco rigido:l'unità stessa non potrebbe rilevare un settore danneggiato, quindi non potrebbe 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 allo scambio di archiviare i dati a lungo termine. Il limite dell'archiviazione di scambio è il tempo di attività del sistema e la maggior parte dei dati nello scambio non dura così a lungo, poiché la maggior parte dei dati che passano attraverso il sistema di memoria virtuale del tuo sistema appartiene a processi di durata molto più breve.
Inoltre, i tempi di attività si sono generalmente ridotti nel corso degli anni, con l'aumento della frequenza di kernel e libc aggiornamenti, virtualizzazione, architetture cloud, ecc.
Inoltre, la maggior parte dei dati in scambio è intrinsecamente in disuso in un sistema ben gestito, essendo uno che non si esaurisce la RAM principale. In un tale sistema, le uniche cose che finiscono nello scambio sono le pagine che il programma non usa spesso, se non mai. Questo è più comune di quanto si possa immaginare. La maggior parte delle librerie dinamiche che i tuoi programmi collegano per contenere routine che il tuo programma non usa, ma dovevano essere caricate nella RAM dal linker dinamico. Quando il sistema operativo vede che non stai utilizzando tutto il testo del programma nella libreria, lo sostituisce, facendo spazio al codice e ai dati che sono i tuoi programmi utilizzando. Se tali pagine di memoria sostituite sono danneggiate, chi lo saprebbe mai?
Confrontalo con ZFS, dove ci aspettiamo che i dati vengano archiviati in modo duraturo e persistente, in modo che durino non solo oltre l'attuale tempo di attività del sistema, ma anche oltre la vita 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. Abbiamo quindi requisiti di rilevamento della corruzione molto più elevati per ZFS rispetto a Linux swap.
ZFS e simili differiscono dallo scambio in un altro modo chiave qui:non scambiamo insieme i filesystem RAID. Quando più dispositivi di scambio sono in uso su una singola macchina, è uno schema JBOD, non come RAID-0 o superiore. (ad es. lo schema dei file di scambio concatenato di macOS, swapon di Linux , ecc.) Poiché i dispositivi di scambio sono indipendenti, piuttosto che interdipendenti come con RAID, non abbiamo bisogno di checksum estesi perché la sostituzione di un dispositivo di scambio non comporta la ricerca di altri dispositivi di scambio interdipendenti per i dati che dovrebbero andare sul dispositivo sostitutivo . In termini ZFS, non resilver 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 utilizzato un contenitore per HDD USB esterno da $ 20 per salvare un pool ZFS in difficoltà, solo per scoprire che il contenitore stesso era inaffidabile, introducendo errori propri nel processo. Il forte checksum di ZFS mi ha salvato qui. Non puoi farla franca con un trattamento così sprezzante dei supporti di memorizzazione con un file di scambio. Se il dispositivo di scambio sta morendo e si sta quindi avvicinando al caso peggiore in cui potrebbe iniettare un errore non rilevabile ogni 125 MiB trasferiti, devi semplicemente sostituirlo il prima possibile.
Il senso generale di paranoia in questa domanda si riduce a un esempio del problema dei generali bizantini. Leggi questo, medita sulla data del 1982 sul documento accademico che descrive il problema al mondo dell'informatica e poi decidi se, nel 2019, hai nuovi pensieri da aggiungere a questo problema. E se no, allora forse ti limiterai a usare la tecnologia progettata da trent'anni di laureati CS che conoscono tutti il problema dei generali bizantini.
Questo è un terreno ben battuto. Probabilmente non riesci a 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 tu non ti unisca al mondo accademico o a uno dei team di sviluppo del kernel, non sarai in grado di aggiungere materialmente allo stato dell'arte qui. Questi problemi sono già a portata di mano, 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 scambio sopra ZFS o Btrfs, ma se quanto sopra non ti rassicura, potresti almeno metterlo sopra xfs o ext4. Sarebbe meglio che usare una partizione di swap dedicata.
Lo scambio ha ??? <--- questa è la mia domanda
Lo scambio non è ancora protetto in Linux (ma vedi UPD).
Beh, ovviamente c'è ZFS su Linux che è in grado di essere un archivio di scambio, ma c'è ancora un blocco in alcune circostanze, revocando così di fatto quell'opzione.
Btrfs non è ancora in grado di gestire i file di scambio. Menzionano il possibile utilizzo del loopback, anche se si nota che ha prestazioni scadenti. C'è un'indicazione poco chiara che Linux 5 potrebbe averlo finalmente (?)…
Le patch per proteggere lo stesso scambio convenzionale con checksum non sono arrivate al mainstream.
Quindi, tutto sommato:no. Linux ha ancora una lacuna.
AGGIORNAMENTO. :Come sottolinea @sourcejedi, esiste uno strumento come dm-integrity. Il kernel Linux dalla versione 4.12 ha ottenuto l'obiettivo del mappatore di dispositivi che può essere utilizzato per fornire checksum a qualsiasi dispositivo di blocco generale e quelli che sono per lo scambio non fanno eccezione. Gli strumenti non sono ampiamente incorporati nelle principali distribuzioni e la maggior parte di esse non ha alcun supporto nel sottosistema udev, ma alla fine questo dovrebbe cambiare. Quando accoppiato con un provider di ridondanza, diciamo messo su un top di MD aka Linux Software RAID, dovrebbe essere possibile non solo rilevare il bit rot ma anche reindirizzare la richiesta di I/O a dati sani perché dm-integrity indicherebbe che c'è un problema e MD dovrebbe gestirlo.
dm-integrità
Vedi:Documentation/device-mapper/dm-integrity.txt
dm-integrity verrebbe normalmente utilizzato in modalità journaling. In caso di scambio, potresti fare a meno del journaling. Ciò potrebbe ridurre significativamente il sovraccarico delle prestazioni. Non sono sicuro se sia necessario riformattare la partizione swap-over-integrity a ogni avvio, per evitare di rilevare errori dopo un arresto non corretto.
Nell'annuncio iniziale di dm-integrity , l'autore dichiara invece una preferenza per la "protezione dell'integrità dei dati al livello superiore". Nel caso dello scambio, ciò aprirebbe la possibilità di memorizzare i checksum nella RAM. Tuttavia, tale opzione richiederebbe modifiche non banali al codice di scambio corrente e aumenterebbe l'utilizzo della memoria. (Le tracce di codice correnti si scambiano in modo efficiente utilizzando estensioni, non singole pagine/settori).
DIF/DIX?
Il supporto DIX è stato aggiunto da Oracle in Linux 2.6.27 (2008).
L'utilizzo di DIX fornisce integrità end-to-end?
Potresti consultare il tuo venditore. Non so come fai a capire se mentono al riguardo.
DIX è necessario per proteggere i dati in transito tra il sistema operativo (sistema operativo) e l'HBA .
DIF da solo aumenta la protezione dei dati in transito 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 fornirne alcun protezione dei dati inattivi. Basta che l'HBA (o il dispositivo di archiviazione) rigeneri il checksum al momento della lettura. Questa prospettiva è stata resa abbastanza chiara dal progetto originale DIX.
- DIF/DIX sono ortogonali ai checksum del blocco logico
- Ti amiamo ancora, btrfs!
- Gli errori di checksum del blocco logico vengono utilizzati per il rilevamento di dati danneggiati
- Il rilevamento avviene all'ora di READ
- ... che potrebbe essere mesi dopo, il buffer originale è andato perso
- Qualsiasi copia ridondante può anche essere danneggiata se il buffer originale è confuso
- DIF/DIX riguardano la prevenzione proattiva della corruzione
- Prevenire innanzitutto l'archiviazione su disco di dati errati
- ... e scoprire i problemi prima che il buffer originale venga cancellato dalla memoria
-- lpc08-data-integrity.pdf da oss.oracle.com
Uno dei loro primi post su DIX menziona la possibilità di utilizzare DIX tra sistema operativo e HBA anche quando l'unità non supporta DIF.
La menzogna completa è relativamente improbabile in contesti "aziendali" in cui DIX è attualmente utilizzato; la gente se ne accorgerebbe. Inoltre, DIF era basato su hardware esistente che poteva essere formattato con settori da 520 byte. Il protocollo per l'utilizzo di DIF richiede presumibilmente di riformattare prima l'unità, vedere ad es. il sg_format comando.
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 end-to-end completa.
In alternativa, un sistema operativo potrebbe generare i propri checksum e memorizzarli nello spazio dei tag dell'applicazione. Tuttavia 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 dei tag dell'applicazione". (Non sono sicuro se questo si riferisca al dispositivo di archiviazione stesso, all'HBA o a entrambi).
Che tipo di dispositivi DIX sono disponibili che funzionano con Linux?
La separazione dei buffer dei dati e dei metadati di integrità, nonché la scelta dei checksum, viene definita Data Integrity Extensions [DIX]. Poiché queste estensioni non rientrano nell'ambito dei corpi del protocollo (T10, T13), Oracle e i suoi partner stanno cercando di standardizzarle all'interno della Storage Networking Industry Association.
-- v4.20/Documentation/block/data-integrity.txt
Wikipedia mi dice che DIF è standardizzato in NVMe 1.2.1. Per gli HBA SCSI, sembra un po' difficile definirlo se non abbiamo uno standard a cui puntare. Al momento potrebbe essere più preciso parlare di supporto "Linux DIX" :-). Sono disponibili dispositivi:
SCSI T10 DIF/DIX [sic] è completamente supportato in Red Hat Enterprise Linux 7.4, a condizione che il fornitore dell'hardware lo abbia qualificato e fornisca il supporto completo per la particolare configurazione dell'HBA e dell'array di archiviazione. DIF/DIX non è supportato su altre configurazioni, non è supportato per l'utilizzo sul dispositivo di avvio e non è supportato sui guest virtualizzati.
Attualmente, i seguenti fornitori sono noti per fornire questo supporto...
-- RHEL 7.5 Note di rilascio, Capitolo 16. Archiviazione
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 diventato disponibile per i dischi SATA consumer - per quanto ne so non esiste nemmeno uno standard de facto per il formato dei comandi. Sarò interessato a vedere se diventa più ampiamente disponibile su NVMe.