Rispondo alle accuse di presunto terrorismo mediatico contro ext4, e sulla presunta inesistenza dei problemi di ext4,
riproponendo come articolo, un mio commento in EXT4 continua il calvario, perchè abbia la giusta visibilità.
Perchè fare una patch, inclusa nel kernel 2.6.32 che recita testualmente:
“ext4: fix cache flush in ext4_sync_file
We need to flush the write cache unconditionally in ->fsync, otherwise
writes into already allocated blocks can get lost. Writes into fully
allocated files are very common when using disk images for
virtualization, and without this fix can easily lose data after
an fdatasync, which is the typical implementation for a cache flush on
the virtual drive.”
fonte: git kernel org
e che chiaramente dice che
“otherwise writes into already allocated blocks can get lost”
“without this fix can easily lose data after an fdatasync”
se NON ESISTE ALCUN PROBLEMA DI PERDITA DATI?
Altro tipico esempio di “already allocated blocks” sono oltre ai dischi virtuali, tutti i file scaricati da programmi p2p dove viene allocata l’intera dimensione e poi riempita man mano che i dati vengono ricevuti.
(cit.) Quindi mi chiedo, perché continuare a fare terrorismo mediatico contro ext4 se non si sa nulla di concreto?
Io non faccio alcun terrorismo, cito le fonti dirette e CONCRETE a differenza di chi sostiene tesi contrarie senza citare NULLA di autorevole a supporto.
Ora la situazione attuale di EXT4 è questa:
senza patch veloce ma possibili perdite di dati in scrittura su blocchi già allocati,
con la patch niente perdite dati ma forte decadimento delle prestazioni ben evidenziato dai test phoronix.
(cit) http://tinyurl.com/ydzqggo
The performance of PostgreSQL in Lucid is absolutely slaughtered when compared to Ubuntu 9.10. In Ubuntu 9.10 it averaged 1910 transactions per second, but with Ubuntu 10.04 LTS right now it is at 114 TPS. However, it is to no surprise and will likely not change. Thanks to our ability to autonomously find performance regressions in the Linux kernel (and you can too with the Phoronix Test Suite), in that same article we pointed out the change that is causing EXT4 in PostgreSQL and some other applications to be much slower in Linux 2.6.32 kernel compared to earlier releases bearing this popular Linux file-system. It was a very simple commit approved by Red Hat that improves the reliability of EXT4 with its default options, but it comes at a severe performance cost for many operations due to flushing the write cache unconditionally in fsync calls.
Qui i nuovi test dei vari filesystem con EXT4 azzoppato dal kernel 2.6.32 che va “peggio” di ext3 (segnalati da sober).
Tutto ciò è figlio del peccato originale di Ext4 con la conseguente diatriba tra lo sviluppatore e gli altri che sviluppano applicazioni, su come vadano scritti correttamente i dati su disco dalle applicazioni (riassunta per brevità qui se vi interessa).
Su chi ha ragione in questa diatriba tra sviluppatori non mi pronuncio, ma chiaramente il “sonno della ragione genera mostri”.
In conclusione, fede equivale a “credere” incondizionatamente, ma io sono agnostico e credo solo nella scienza che è fatta di teorie e dimostrazioni ripetibili, e sono stufo di leggere affermazioni o accuse bastate sul nulla cosmico eccepite alle mie considerazioni, basate invece, perlomeno nel caso specifico, su cose ben documentate e riportate in originale.
