Newsgroup: it.comp.os.dibattiti
Titolo: journaling vs softupdates

Ciao,
stavo leggendo
http://kerneltrap.org/node/view/4367
e c'e' un punto che non ho capito:
"While we can debate the merits of speed and data integrety of 
journalling vs. softupdates, ..."
Ho sempre creduto che i softupdates fossero il journal dell'UFS, ma 
evidentemente mi sbagliavo. C'e' qualcuno che potrebbe spiegarmi la 
differenza?
Ciao
Scola

 
 premetto che _una volta_ lo sapevo ma adesso non me lo ricordo piu ' ,
 comunque "the source is the documentation"
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/README.softupdates?rev=1.9&content-type=text/x-cvsweb-markup
un paio di link:
http://www.usenix.org/publications/library/proceedings/usenix2000/general/seltzer.html
http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/


Molto sinteticamente:
i fs journaled scrivono prima nel journal ogni aggiornamento del fs,
metadati e/o dati.  Una volta che sono nel journal possono essere
tranquillamente copiati nel fs e rimossi dal journal che è gestito
come una coda circolare.
Se il sistema va in crash prima che il fs sia stato smontato
correttamente, al prossimo mount viene fatto il "replay" del journal
riportando i metadati e/o dati del fs alla consistenza.
E' un'operazione totalmente trasparente all'utente e che dura mediamente
un paio di secondi, indipendentemente dalla dimensione del fs.
FFS con le SU affronta il problema diversamente.  Invece di scrivere
gli aggiornamenti temporaneamente in un journal, mantiene in memoria
un grafo delle dipendenze dei blocchi da aggiornare (nel dettaglio non è 
proprio così ma il concetto è questo) e aggiorna i metadati del fs 
rispettando le dipendenze.  In questo modo ci si assicura che in ogni
momento il fs sia sempre consistente e che le uniche inconsistenze
che possono verificarsi sono blocchi o inode dichiarati usati quando
invece non lo sono.  Al prossimo reboot (se il sistema era andato in crash)
è dunque possibile montare il fs così com'è senza bisogno di fare il
check con fsck.  Tuttavia nei casi in cui si vuole recuperare
lo spazio perso è necessaria una passata di fsck in foreground nei FreeBSD 
4.x o in alternativa in background nei 5.x.
FS journaled based e SU sono due approcci ortogonali per risolvere lo
stesso problema.  I primi usano delle tecniche collaudate da anni nei
database, i secondi usano un metodo per minimizzare il numero di scritture
per ogni aggiornamento.
I fs journaled hanno il vantaggio che sono più semplici e una volta montato
il fs sono sempre totalmente consistenti e non hanno bisogno d'altro.
Hanno lo svantaggio teorico delle doppie scritture (journal e fs) per ogni
aggiornamento, tuttavia le scriture che avvengono nel journal sono 
sequenziali e per questo molto veloci, inoltre sono anche asincrone.
Questo fa si che in pratica i fs journaled abbiano delle ottime prestazioni
comparabili o superiori a FFS con SU.
Ho svolto personamente alcuni test qualche tempo fa con il FFS di FreeBSD 
5.2 ed ext3 di linux 2.6 e quest'ultimo ha battuto FFS in 4 test su 4.

 5.2 ed ext3 di linux 2.6 e quest'ultimo ha battuto FFS in 4 test su 4.
Senza configurazioni alla mano e con un OS in pieno sviluppo sono un po' 
test alla "Windows su Intel costa meno di Linux su supercomputer".
Magari se li rifai posta qui, cosi' si ottimizza il tutto (cioe' io ti
aiuto con FreeBSD, per Linux saprai tu che fare).
Che bench hai usato ? Bonnie ? Sarebbe bello usare pgbench, cosi' si
testa in ambienti reali per cose reali.
HAND,
  ngw
-- 
checking for life_signs in -lKenny... no
	Oh my god, make (1) killed Kenny ! You, bastards !
nicholas_wieland-at-yahoo-dot-it

 testa in ambienti reali per cose reali.
time { tar zxf <sorgenti-OOo1.0.tar.gz> ; sync; }
time { grep "fuffa" <sorgenti-OOo1.0> -r; sync; }
time { cp -a <sorgenti-OOo1.0> <dest>; sync; }
time { rm -r <sorgenti-OOo1.0>; sync; }
Ogni test l'ho fatto girare con cache fredda (umount/mount cycle)
in modo da analizzare solo le prestazioni del fs.
sync serve ad ottenere risultati riproducibili e far svolgere lo
stesso lavoro a entrambi i fs.
Ho scelto questi test perchč sono operazioni reali e abbastanza
comuni, pgbench non lo conosco ma credo di aver capito cos'č :)
Tutti i test li ho condotti su stesso hw, stesso hd, stessa partizione
con FreeBSD 5.2 in dual boot, cosa non ho ora..

 
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/README.softupdates?rev=1.9&content-type=text/x-cvsweb-markup
si, ma siccome il gruppo di documentaziomne ha tradotto iun italiano un 
bel pezzo dell'handbook che lo spiega, magari conviene prima leggere 
quello :)

 quello :)
pensavo l'avesse letto prima di postare e non ci avesse trovato niente ...