Ho familiarità con ciò che una BBWC (cache di scrittura supportata da batteria) è destinata a fare - e li ho precedentemente utilizzati nei miei server anche con un buon UPS. Ci sono ovviamente fallimenti per cui non fornisce protezione. Sono curioso di capire se in realtà offre qualche reale vantaggio.
(NB Sto specificatamente cercando risposte da persone che hanno BBWC e hanno avuto crash / fallimenti e se il BBWC ha aiutato il recupero o meno)
Aggiornare
Dopo il feedback qui, sono sempre più scettico sul fatto che un BBWC aggiunga valore.
Per avere fiducia nell'integrità dei dati, il filesystem DEVE sapere quando i dati sono stati sottoposti a memorizzazione non volatile (non necessariamente il disco - un punto su cui tornerò). Vale la pena notare che molti dischi mentono su quando i dati sono stati impegnati sul disco ( http://brad.livejournal.com/2116715.html ). Anche se sembra ragionevole supporre che la disabilitazione della cache su disco possa rendere i dischi più onesti, non è ancora garantito che sia così.
A causa dei buffer tipicamente grandi in un BBWC, una barriera può richiedere un numero significativamente maggiore di dati da trasferire su disco, causando ritardi nelle scritture: il consiglio generale è di disabilitare le barriere quando si utilizza una cache di riscrittura non volatile (e disabilitare on- memorizzazione nella cache del disco). Tuttavia, ciò sembrerebbe minare l'integrità dell'operazione di scrittura - solo perché un numero maggiore di dati viene conservato in un archivio non volatile non significa che sarà più coerente. In effetti, senza dubbio, senza demarcazione tra le transazioni logiche, sembra che ci sia meno opportunità di garantire coerenza che in altro modo.
Se la BBWC dovesse riconoscere le barriere nel momento in cui i dati entrano nella sua memoria non volatile (piuttosto che impegnarsi su disco), sembrerebbe soddisfare i requisiti di integrità dei dati senza una penalità di prestazione, il che implica che le barriere dovrebbero essere ancora abilitate. Tuttavia, poiché questi dispositivi presentano generalmente un comportamento coerente con lo scaricamento dei dati sul dispositivo fisico (significativamente più lento con le barriere) e i consigli diffusi per disabilitare le barriere, non possono quindi comportarsi in questo modo. PERCHÈ NO?
Se l'I / O nel sistema operativo è modellato come una serie di flussi, esiste un margine per ridurre al minimo l'effetto di blocco di una barriera di scrittura quando la cache di scrittura è gestita dal sistema operativo, poiché a questo livello solo la transazione logica (un singolo flusso ) deve essere impegnata. D'altra parte, un BBWC senza sapere quali bit di dati compongono la transazione dovrebbe impegnare l'intera cache su disco. Se il kernel / filesystem effettivamente implementerà questo in pratica richiederebbe molto più sforzo di quello che sto per investire al momento.
Una combinazione di dischi che raccontano le ragioni di ciò che è stato commesso e la perdita improvvisa di potere indubbiamente porta alla corruzione - e con un filesystem strutturato su Journalling o log che non fa un completo colpo dopo un'interruzione è improbabile che la corruzione venga rilevata e tanto meno un tentativo di ripararlo.
In termini di modalità di guasto, nella mia esperienza la maggior parte delle interruzioni improvvise si verificano a causa della perdita di alimentazione di rete (facilmente mitigabile con un UPS e spegnimento gestito). Le persone che tirano il cavo sbagliato dal rack implicano una scarsa igiene del datacenter (etichettatura e gestione dei cavi). Esistono alcuni tipi di eventi improvvisi di perdita di potenza che non sono evitati da un UPS: un guasto nell'alimentatore o VRM un BBWC con barriere fornirebbe integrità dei dati in caso di guasto qui, tuttavia quanto sono comuni tali eventi? Molto raro a giudicare dalla mancanza di risposte qui.
Certamente spostare la tolleranza ai guasti più in alto nello stack è significativamente più costoso di un BBWC, tuttavia l'implementazione di un server come cluster ha molti altri vantaggi in termini di prestazioni e disponibilità.
Un modo alternativo per mitigare l'impatto di un'improvvisa perdita di potenza sarebbe quello di implementare una SAN - AoE rende questa una proposta pratica (non vedo davvero il punto in iSCSI) ma di nuovo c'è un costo più elevato.
