Non stai essenzialmente scrivendo due volte gli stessi dati sul disco? Questo non causa un rallentamento di un fattore di ~ 2x?
Quali ottimizzazioni possono essere fatte per minimizzare il costo di dover scrivere cose due volte?
Non stai essenzialmente scrivendo due volte gli stessi dati sul disco? Questo non causa un rallentamento di un fattore di ~ 2x?
Quali ottimizzazioni possono essere fatte per minimizzare il costo di dover scrivere cose due volte?
Sì, stai scrivendo due volte gli stessi dati. Questo è precisamente il punto di un file system di journaling . Sono destinati all'affidabilità rispetto alle prestazioni. Utilizzando la registrazione write-ahead, eliminano (virtualmente) qualsiasi rischio di corruzione dei dati, perché se il sistema si arresta in modo anomalo nel mezzo di una scrittura di dati, possono semplicemente riprodurre il log e ripristinarlo di conseguenza.
L'alternativa migliore di cui sono a conoscenza che offre prestazioni migliori è copia su scrittura , che è sorta di un file system "immutabile". Non aggiorna mai sul posto; invece, scrive i nuovi dati in una nuova area del disco e solo dopo che ha avuto successo aggiorna i metadati e indirizza nuove richieste ai nuovi dati. Questo ha migliori caratteristiche prestazionali, ma è anche più soggetto a frammentazione e richiede molta capacità extra (specialmente se stai scrivendo un file enorme).
Se ci sono altre tecniche che hanno le stesse caratteristiche di affidabilità, allora non penso che nessuno di loro sia in uso molto comune oggi. Principalmente vedi solo l'inserimento nel journal e COW.
Altri hanno affrontato il motivo per cui ciò causa di fatto un rallentamento. Ecco alcuni modi per mitigarlo:
Alcuni filesystem journalano tutto tranne il contenuto del file. Ciò significa che il filesystem stesso sarà sempre in uno stato coerente anche se i dati nei file non lo sono. Ciò offre prestazioni migliori rispetto al journaling di tutto.
Un'altra opzione è un file system log-strutturato , che consiste essenzialmente in un solo diario. Le scritture sono incredibilmente veloci e la coerenza è garantita. Lo svantaggio è che legge è molto più lento, perché ogni lettura è un replay del diario. Ciò rende anche più complesse le cancellazioni e la garbage collection.
Hai ragione nel dire che Journalling aumenta il carico di scrittura, tuttavia, il costo di fare due scritture come questa è abbastanza minimo, e in genere ha un certo numero di cache nella cache e può essere ottimizzato anche in altri modi.
Peggio di Journalling, operazioni rallentate in modo problematico in genere comportano operazioni ordinate write > read- > write, come tendono a verificarsi in uno scenario RAID-5, in cui è necessario leggere il settore non di parità che i dati vengono scritti è accoppiato con, al fine di calcolare i dati del settore di parità. (Per questo motivo, RAID-1 è preferibile a RAID-5 nei sistemi che leggono e scrivono molti piccoli file, ma RAID-5 vince per i file più grandi che verrebbero utilizzati nella produzione video, poiché questa sequenza WRW può essere convertita in WWW se sovrascrivi entrambi i settori di dati AND il settore di parità.)
In alternativa, ZFS utilizza in particolare la semantica Copy-on-Write, in cui i nuovi dati del file vengono scritti su una parte vuota del disco, quindi i settori dei metadati vengono aggiornati (in genere in una singola operazione) in modo che non importa quando l'operazione viene interrotta, non c'è mai uno stato di file incoerente.
Tutto sommato, Journalling è abbastanza economico per i benefici che offre, ma ci sono ovviamente dei costi per l'implementazione o qualsiasi altra contromisura di corruzione del file system. YMMV.
Leggi altre domande sui tag file-systems logging