Tecnologia e non solo

dicembre 13, 2009

EXT4: terrorismo mediatico?

Filed under: Acid,hardware,Noia — telperion @ 1:16 pm

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.

25 commenti

  1. Scoccia sempre sentir dare addosso alla propria distro/dm/fs/quelcheè preferito, è istintivo un po’ in tutti, ammetto che quando inveli ubuntu un po’ li per li l’adrenalina si alza, però bisogna anche aver l’oinestà intellettuale di capire quando le critiche sono fatte tanto pe rdare aria alla bocca, e quando, questo è generalmente il tuo caso, sono basate su dati reali.

    E ai dati bisogna contrapporre dati, non aria fritta😛

    Commento di Cobra78 — dicembre 13, 2009 @ 1:58 pm

    • Ma comunque la cosa non riguarda “Ubuntu”, ma TUTTI i kernel 2.6.32 ed ext4. Addirittura non conoscendo la politica dei kernel ubuntu, la patch citata *potrebbero* averla applicata anche al 2.6.31, io questo non lo so, ne posso conoscere le specifiche decisioni dei vari mantainer delle varie distribuzioni.
      Per questi motivi mi riferisco sempre al vanilla kernel, cioè al mainline.

      Commento di telperion — dicembre 13, 2009 @ 2:33 pm

  2. Stando così le cose, si hanno dei benchmark comparativi tra un ext3 e questo nuovo ext4 patchato “unconditionally”?
    Secondo me è l’unica cosa interessante al momento.

    Un altra cosa interessante: ci sono delle opzioni di avvio del filesystem (fstab) che ripristinerebbe la precedente “possibilità di perdita dati” mantendendo il precedente livello di prestazioni? In pratica qualcosa che dica al sistema “non farmi sentire gli effetti del commit, voglio stare sul filo del rasoio come prima, ma col nuovo kernel..”

    Commento di stefanauss — dicembre 13, 2009 @ 1:59 pm

    • 1) Test ext3-ext4 generici ne trovi alcuni qui
      http://tinyurl.com/5ebp97
      per farti un’idea.

      2) No puoi solo fare il contrario, sui kernel precedenti, con l’opzione

      nodelalloc
      Disable delayed allocation.
      Blocks are allocation when data is copied from user to page cache.

      fonte
      http://tinyurl.com/yah5zn8

      Comunque la situazione è in movimento
      penso che gia nel 2.6.32.1 ci saranno modifiche, apri la pagina
      http://tinyurl.com/y9gmekw
      e cerca fs/ext4 vedrai molti cambiamenti, compreso fs/ext4/fsync.c

      Commento di telperion — dicembre 13, 2009 @ 2:45 pm

  3. Questa storia di ext4 comicia a diventare a tratti quasi comica. Le domande da porsi, a parer mio, sono due: perchè ext4 è stato rilasciato come stabile quando, palesemente, non lo era? E perchè alcune distribuzioni hanno deciso di formattare i dischi con ext4 di default pur essendo a conoscenza di tutti questi problemi?

    Commento di firstbit — dicembre 13, 2009 @ 8:07 pm

    • Perchè dal punto di vista del filesystem, ext4 è a posto.
      Se leggi la diatriba, vedi che si discute sul modo di scrivere i dati dalle applicazioni, con botta e risposta delle parti in causa.
      Il problema detto in parole povere nasce da come viene svuotata la cache in scrittura dai vari programmi.

      Sulle distribuzioni,
      la patch datata Sun 6 Sep 2009 e approvata da Red Hat (vedi citazione phoronix), è entrata in mainline solo ora col 2.6.32, ma presumo che fedora “potrebbe” usarla da tempo (non lo so, lo presumo) quindi distribuzioni che l’hanno adottata, hanno un ext4 più lento ma sicuro, le altre che hanno un kernel 2.6.31 senza questa patch, potenzialmente sono a rischio, non mi chiedere quali sono e con che versione di kernel, perchè non ne ho idea …
      Sicuramente quelle col 2.6.32 hanno la patch.

      Commento di telperion — dicembre 13, 2009 @ 8:20 pm

      • Effettivamente stanno litigando un po’ troppo per i miei gusti. È evidente che qualcosa non va: speriamo che lavorino di più per sistemare e perdano meno tempo a mordersi le chiappe a vicenda.

        Nel frattempo i commit che riguardano ext4 continuano di giorno in giorno; non li ho letti tutti ma sembra che qualcosa si muova.

        Commento di firstbit — dicembre 14, 2009 @ 9:14 am

  4. ma sono solo io che ho quello che funziona ?
    mai avuto problemi, con nessuna versione del kernel e con nessuna distro. mai notato rallentamenti di alcun tipo ne particolari vantaggi prestazionali rispetto a ext3 (certo, sto parlando in modo aleatorio e non con benchmark precisi). ma soprattutto, mai perso un bit.
    eppure (pur usando per la gran parte del tempo OSX quindi HFS) per quel poco che sto usando linux, ho distro su ext4. mah.

    Commento di LuNa — dicembre 14, 2009 @ 8:34 am

  5. phoronix ha pubblicato stamattina dei nuovi test sul 2.6.32. Ext3 distrugge ext4 in prestazioni.
    http://www.phoronix.com/scan.php?page=article&item=linux_2632_fs&num=1

    Commento di sober — dicembre 14, 2009 @ 12:10 pm

    • Grazie della segnalazione, ho aggiunto il limk all’articolo.

      Commento di telperion — dicembre 14, 2009 @ 12:29 pm

    • oh, grazie sober. quando ho sottolineato che sarebbe stato utile pubblicare/linkare un confronto ext3-ext4 (col kernel 2.6.32, ovvio, di questo si stava parlando) mi è stato risposto che non so leggere i test e di astenermi dal commettarli O_O

      Commento di grabber — dicembre 15, 2009 @ 9:50 am

      • I test li hanno pubblicati ieri, prima dovevi, come chiunque dotato di intelletto farebbe, fare le valutazioni riferendoti ai precedenti di ext3 vs ext4, confrontatoli con gli ultimi ext4, mi sembra più che ovvio.
        Non è che la pappa è sempre pronta e calda al tuo volere.
        I nuovi test tra l’altro, confermano la valutazione di degrado delle prestazioni di ext4, a conferma del fatto che i test “bisogna saperli leggere”, altrimenti inutile commentare.

        Commento di telperion — dicembre 15, 2009 @ 12:12 pm

      • sorvolo direttamente sul tuo tono inutilmente arrogante per farti notare che io *non ho* fatto alcuna valutazione sulle prestazioni di ext3/ext4, mi sono limitato a sottolineare passaggi presenti negli articoli phoronix. siccome poi hai scritto “ext3 sicuro ma lento, ext4 con kernel < 2.6.32 veloce ma potenzialmente insicuro, ext4 con kernel 2.6.32 sicuro (forse) ma lento come o più di ext3 …", la curiosità mi è sorta spontanea "ma effettivamente quanto è più lento?"… che tra l'altro non era neanche una richiesta indirizzata espressamente a te.
        senza rancore eh.

        Commento di grabber — dicembre 15, 2009 @ 1:18 pm

      • Eppur si muove … ma all’indietro , secondo quanto scritto alla fine dei tests di Phoronix : ” … Stay tuned to Phoronix though as the EXT4 performance is set to get even worse later with the Linux 2.6.33 kernel, which we will talk about later this week “

        Commento di linuser — dicembre 15, 2009 @ 4:38 pm

  6. Greg Kroah-Hartman posted a series of review patches for the forthcoming 2.6.31.8 and 2.6.32.1 stable kernels, including a large number of ext4 fixes, and an obscurely unlikely stack corruption on 2.6.32

    http://www.kernelpodcast.org/2009/12/14/20091210-linux-kernel-podcast/

    Commento di telperion — dicembre 14, 2009 @ 11:39 pm

  7. 2.6.32.1

    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.1

    con una “marea” di cambiamenti in ext4 …
    (l’80% del changelog è riferito a ext4)

    Più o meno gli stessi cambiamenti anche nel 2.6.31.8

    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.31.8

    Commento di telperion — dicembre 15, 2009 @ 11:49 pm

  8. Scusate l’intervento che non c’entra una mazza….
    Innanzitutto grazie a Telperion per avermi fatto scoprire il sito di Phoronix che fino a ieri pensavo fosse una marca di asciugacapelli.🙂
    Sul sito ci sono i test….direi molto recenti….sia riguardanti EXT4 che il kernel 2.6.32…e mi domando….non li ho saputi interpretare io…..o siamo di fronte ad una grossa regressione dal punto di vista prestazionale?

    Commento di Scugnizzo — dicembre 16, 2009 @ 12:07 pm

    • Si ext4 è sicuramente regredito,
      è non è neppure sicuro nonostante le modifiche:
      ieri freeze del mio pc con ext4, reset, file di configurazione di amule azzerato, ho dovuto reimpostare tutto daccapo, ed era il kernel 2.6.32 quello “lento ma sicuro”.
      E stic4zzi!!!

      Commento di telperion — dicembre 16, 2009 @ 12:19 pm

      • Azzz….te la sei chiamata!!🙂
        Sinceramente io uso il 2.6.31 (quello di Canonical) con ext4 sul disco dove installo le machcine virtuali….e finora nessun problema (grattatio pallorum omni mala fugat).

        Commento di Scugnizzo — dicembre 16, 2009 @ 12:46 pm

      • E ma il punto è proprio quello:
        il fatto che non ti sia mai capitato non esclude per nulla che ti possa capitare.
        Che non è esattamente il massimo per un filesystem.

        Tra l’altro il 2.6.32.1, nonostante i molti cambiamenti di codice, ha le stesse performance ridotte del 2.6.32

        http://global.phoronix-test-suite.com/index.php?k=profile&u=mc-29271-23246-17060

        quanto a sicurezza dei dati affidiamoci a San Gennaro, sicuramente più affidabile …
        LOL

        Commento di telperion — dicembre 16, 2009 @ 3:14 pm

      • Ma in quel test il 2.6.32 c’ha una unità disco in più collegata (164gb L160P0…sembra una unità usb)…..può questo incidere sui risultati del test?

        Commento di Scugnizzo — dicembre 16, 2009 @ 4:36 pm

      • No, la partizione con ubuntu è su 500GB MAXTOR STM350032 ed è la stessa per entrambi i test, che sono in linea con quelli di phoronix 679 con 31 e 120 col 32

        http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1

        Commento di telperion — dicembre 16, 2009 @ 5:27 pm

  9. Leggo da ossblog che il mantainer di ext3 e ext4 è stato assunto da Google , in previsione di una transizione di tutti i suoi datacenter da ext2 a ext4.

    Sono stati effettuati degli intensi benchmarks con i filesystems jfs ,xfs e ext4 e quest’ultimo è risultato essere il filesystem più idoneo per la transizione : http://lists.openwall.net/linux-ext4/2010/01/04/8

    “For our workloads we saw ext4 and xfs as “close enough” in performance
    in the areas we cared about. The fact that we had a much smoother
    upgrade path with ext4 clinched the deal. The only upgrade option we
    have is online. ext4 is already moving the bottleneck away from the
    storage stack for some of our most intensive applications.”

    Sebbene ext4 e xfs siano risultati abbastanza vicini come performance assolute , la scelta è ricaduta sul primo per via di una procudura di upgrade più pulita.

    Sicuramente l’occasione per avere più stabilità in ext4.

    Commento di linuser — gennaio 15, 2010 @ 4:20 pm

  10. Nei nuovi test di oggi su Phoronix EXT4 su Lucid risulta nel complesso il filesystem più veloce, rispetto a Karmic EXT4,EXT3 e BTRFS, e anche rispetto a Lucid EXT3, BTRFS..

    Commento di vervelover — febbraio 19, 2010 @ 11:42 am


RSS feed for comments on this post.

Blog su WordPress.com.

%d blogger cliccano Mi Piace per questo: