Tecnologia e non solo

dicembre 11, 2009

EXT4 continua il calvario.

Filed under: Edicola,hardware — telperion @ 1:33 pm

Non c’è pace per il nuovo filesystem.
Dopo i vari problemi di possibile perdita di dati, forse risolti, forse no, il tutto è molto ambiguo, con il nuovo kernel 2.6.32 le prestazioni, unico motivo per preferirlo al lento ext3, sono crollate.

postgrep bench

L’entità della regressione è preoccupante, qui gli articoli di Phoronix:

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

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

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

Questo il commit che genera la regressione, come dire rendiamo sicuri i dati, sopratutto nei dischi virtuali (ancora un altro problema?) ma al costo di un fortissimo rallentamento in scrittura.

Uhm, a questo punto tanto vale tornare al vecchio ext3 allora, almeno sicuramente è “sicuro” …

Che dire, se usate ext4 state lontani da questo kernel, a meno che non risolva gravi problemi con il vostro hardware.

Ext4 sembra nato sotto una cattiva stella.
Peccato perchè sicurezza dei dati e prestazioni, sono fortemente dipendenti dal filesystem usato.

Ora abbiamo:
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 …

Le conclusioni le lascio a voi,
io sto col 2.6.31 ed ext4 accollandomi il "rischio".

Non c’è pace tra gli ulivi

31 commenti

  1. la mia scheda sd di espansione su aspire one ieri non voleva essere montata all’avvio, ha ext4 e un fsck ha trovato e corretto diversi errori. Ora funziona, avevo pensato che fosse per colpa dell’inaffidabilità delle schede sd (comunque stava lì nel suo slot di espansione, nessuno l’ha toccata, e non ho mai sospeso il computer), ma ora temo che il problema sia ext4.. davvero un brutto affare per lucid..

    Commento di vervelover — dicembre 11, 2009 @ 2:14 pm

    • Comunque per supporti solidi i fs migliori sono ext2 o fat32 se multisistema, perchè il journaling di ext3/4 o nfts stressa inutilmente le celle con molte scritture, e il numero di scritture è limitato sulle memorie solide.

      Commento di telperion — dicembre 11, 2009 @ 3:13 pm

  2. Questo 2.6.32 ha portato un ottimo stack wifi, ma disastro sul fronte filesystem e anche qualche fromboliata sulle balle rispetto al reboot del mio PC che adesso, anzichè caricare il BIOS, continua a fare le lucine intermittenti. Mah.

    Commento di Bl@ster — dicembre 11, 2009 @ 3:18 pm

    • Beh potresti fare il revert di quel commit di ext4 per tornare ad avere la velocità del fs, per il resto non saprei, non ho compilato ne installato nessun 2.6.32.

      Commento di telperion — dicembre 11, 2009 @ 3:30 pm

      • è vero, ma ext4 lo consigliano su aspire one perchè la scheda ssd integrata con ext2 è lenta, e ho letto che pure su sd normali è veloce..

        Commento di vervelover — dicembre 11, 2009 @ 6:49 pm

  3. speriamo in btrfs…

    Commento di Giorg — dicembre 11, 2009 @ 4:41 pm

    • Anche in sgflg …
      (San Gennaro Facci La Grazia)😀

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

  4. ho letto tutti gli articoli. qualche appunto:
    – il primo articolo che hai linkato si riferisce al kernel Linux 2.6.32-rc5 ed è stato effettuato il 22 ottobre.
    – i rallentamenti sono stati rilevati solo sulle transazioni postgre e sqlite e , molto meno marcatamente, con apache benchmark
    – i risultati del 3° link che hai pubblicato specificano che per Iozone in write i benchmark dei kernel sono sostanzialmente simili, per Iozone in read e la riduzione della velocità non è imputabile al kernel, per Dbench 4.0 lo è solo parzialmente
    sono un po’ meno preoccupato adesso😉

    Commento di grabber — dicembre 11, 2009 @ 6:23 pm

    • La perdita in velocità è ovviamente solo in scrittura e con i file piccoli, per via dei continui “flush the write cache” introdotti dal commit, che vanificano totalmente i benefici del delayed allocation. Praticamente si torna a ext3.

      Chiaramente non influiscono sul test iozone che scrive file da 512KB-8GB.

      Però nell’uso di tutti i giorni il s.o. scrive continuamente piccoli file, log configurazioni, sqlite dei vari programmi, e tutte queste operazioni sono molto rallentate.

      Copiare file da centinaia di KB è un’operazione che percentualmente avviene raramente nell’uso del s.o. rispetto alle centinaia di scritture di piccoli file che avvengono continuamente.

      Ecco perchè Phoronix parla di regressione, il dato su postgresql è disastroso,
      e con sqlite preoccupante.

      Per dire solo Firefox quando lo usi, apre e scrive:

      content-prefs.sqlite permissions.sqlite urlclassifier3.sqlite
      cookies.sqlite places.sqlite urlclassifier.sqlite
      downloads.sqlite search.sqlite webappsstore.sqlite
      dta_queue.sqlite signons.sqlite
      formhistory.sqlite urlclassifier2.sqlite

      Commento di telperion — dicembre 11, 2009 @ 8:50 pm

  5. Nel kernel 2.6.32 sono stati introdotti anche dei miglioramenti allo scheduler di default CFS e alla gestione della memoria : lo sto usando sulla mia test box ( con Debian Unstable ) sin dalla rc8 , ma non uso il vanilla ; uso invece il ramo zen ( http://zen-kernel.org/releases ) . Quello che ho notato ( dmesg con supporto alla visualizzazione del timing abilitato ) è che il boot è più veloce rispetto al kernel della serie 2.6.31 ( 2.6.31-zen9 basato su zen-stable ) di circa 4/5 secondi , la responsività generale del sistema è equivalente anche perchè hanno backportato le migliorie al CFS sul ramo zen-stable. Per quanto riguarda il filesystem , uso da sempre reiserfs 3 che magari non è più mantenuto regolarmente ma almeno è più stabile. Credo che il futuro sia comunque btrfs , ma chissà quando raggiungerà una stabilità accettabile.

    Per quanto riguarda le tre lucine lampeggianti , di solito indicano un kernel panic ma mi sembra strano che appaiano al reboot e quindi _prima_ che il kernel sia caricato:/

    O il panic avviene al momento della chiamata per il reboot , quindi prima del reboot effettivo , oppure se hai Grub2 e partizioni separate per /boot e / , ci potrebbe essere qualche problema con le partizioni : http://bbs.archlinux.org/viewtopic.php?id=85680

    Commento di linuser — dicembre 11, 2009 @ 11:05 pm

  6. senza contare poi che sarebbe stato utile nei test anche una comparazione tra le prestazioni ext3 e ext4.
    scusa ma non riesco mai a digerire troppo facilmente i test di phoronix (di qualunque tipo siano). troppe variabili in campo per farne di tutta un’erba un fascio.

    Commento di grabber — dicembre 12, 2009 @ 11:24 am

    • Beh, se non sai valutare le indicazioni dei test, magari astieniti dal commentarli.
      Se non capisco nulla di fisica quantistica, io evito di scrivere sui blog che ne parlano.😉

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

      • diamine, hai ragione.
        dimenticavo la semplice correlazione: chiedere test più esaustivi = incapacità di valutare i test.
        ma per cortesia.

        Commento di grabber — dicembre 12, 2009 @ 2:30 pm

      • I test di comparazione ext3/ext4 sono stati fatti quando è uscito ext4 (2.6.28 se non ricordo male) invece di chiedere, cercali sul sito di phoronix, o anche sul mio blog visto che li ho fatti pure io.
        😉

        Commento di telperion — dicembre 12, 2009 @ 2:59 pm

  7. mappork, i motivi per usare il kernel 2.6.32 ci sono.. per esempio molte schede radeon recenti non hai più bisogno dei driver fglrx proprietari http://grigio.org/habemus_driver_addio_fglrx_ubuntu_9_10_karmic

    Commento di grigio — dicembre 12, 2009 @ 12:58 pm

    • infatti ho scritto

      “Che dire, se usate ext4 state lontani da questo kernel, a meno che non risolva gravi problemi con il vostro hardware.”

      Commento di telperion — dicembre 12, 2009 @ 3:00 pm

      • Beh a questo punto visto che il problema che tu poni è relativo a un solo modulo e imputato a 3 linee di codice, invece di riassumere con “se usate ext4 , state lontani da questo kernel ” , personalmente chiuderei con “non usate ext4 perchè _non è sufficientemente maturo_ “

        Commento di linuser — dicembre 12, 2009 @ 5:18 pm

      • Si infatti, l’articolo vuole semplicemente informare sui vantaggi e svantaggi di ext4, l’aumento di performance rispetto ad ext3 io lo reputo notevole e ne accetto gli eventuali rischi.
        Gli altri secondo me, è bene che valutino attentamente pro e contro a seconda delle loro esigenze e del valore dei propri dati, ma per farlo devono essere informati, non rassicurati dai banali messaggi che si leggono nei forum, tipo:
        “non c’è nessun problema”,
        “a me non è mai successo nulla”
        eccetera, tra l’altro senza citare alcuna fonte autorevole, io cito e rimando al commit di kernel.org e ai test di phoronix che non mi sembrano gli ultimi incompetenti del pianeta.
        Spero che qualcuno colga la sottile differenza tra chiacchiere da bar senza fondamento, e “fatti” documentati, perchè mi sto un po rompendo le scatole (e non mi riferisco certo a te).
        Questo è l’unico motivo per cui scrivo qui le mie considerazioni, per condividerle.
        Io le mie scelte le ho già fatte.😉

        Commento di telperion — dicembre 12, 2009 @ 6:50 pm

  8. @Tutti
    L’articolo è riferito alle regressioni di Ext4 dovute al citato commit nel kernel 2.6.32 e ben documentate da Phoronix con i suoi test oggettivi.
    Non voglio essere scortese ma divagazioni sulla rava e la fava o valutazioni soggettive, mi fanno solo perdere tempo e non mi interessano, quindi d’ora in poi elimino tutto quello che non è pertinente con l’argomento in discussione.

    Commento di telperion — dicembre 12, 2009 @ 3:36 pm

  9. Ok, questi dati arrivano da fonti attendibili (Phoronix) e non ho intenzione di confutarli.
    Peró é evidente il fatto che se uno resta con ext4 sul kernel 2.6.31 non ci sono problemi, poi sará il team di sviluppo di ext4 che lavorerá per correggere il problema con i kernel 2.6.32. Non dimentichiamo che il kernel 2.6.32 é nuovissimo e pertanto potrebbe anche trattarsi di qualcosa legato al kernel stesso.
    Certo, direte voi, ext4 ha una probabile falla, che teoricamente potrebbe far perdere dei dati. Conosco questa storia, ho letto abbastanza in giro, l’ unica cosa certa che ho imparato é che nessuno sa con certezza se questo bug esiste o no, inoltre se guardiamo su internet, non si trovano piú di una manciata di utenti che sono stati toccati da questo problema, quindi probabilmente dovuto a particolari situazioni, particolari HW, particolari ecc.
    Quindi mi chiedo, perché continuare a fare terrorismo mediatico contro ext4 se non si sa nulla di concreto?

    Commento di Smurf — dicembre 12, 2009 @ 7:17 pm

    • La risposta alla tua domanda (pertinente per cui ti rispondo)
      è logica se ci ragioni.

      Perchè fare una patch 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.”

      che chiaramente dice che SENZA
      “otherwise writes into already allocated blocks can get lost”

      se NON ESISTE IL 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, so leggere a differenza di te evidentemente, pieno di false certezze basate sul nulla più totale; TU non hai NULLA DI CONCRETO a sostegno delle tue ipotesi, se non chiacchiere da bar basate sul nulla cosmico.

      Ora la situazione di EXT4 è questa:
      senza patch veloce ma possibili perdite di scrittura dei dai in 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.

      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.
      Su chi ha ragione non mi pronuncio, ma chiaramente il “sonno della ragione genera mostri”.

      Eccheccaz… il cervello accendilo ogni tanto.
      Fede equivale a “credere” incondizionatamente, ma io sono agnostico e credo solo nella scienza che è fatta di teorie e dimostrazioni ripetibili.

      Commento di telperion — dicembre 12, 2009 @ 8:43 pm

    • > Peró é evidente il fatto che se uno resta con ext4 sul kernel 2.6.31 non ci sono problemi …
      > Non dimentichiamo che il kernel 2.6.32 é nuovissimo e pertanto potrebbe anche trattarsi di qualcosa legato al kernel stesso.

      No e no : il kernel 2.6.32 non è nuovissimo lo sviluppo è a ciclo continuo ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary ) , non parte da zero ogni volta ; è ext4 che aggiunge funzionalità non certamente nuove al filesystem della serie ext*

      > Certo, direte voi, ext4 ha una probabile falla, che teoricamente potrebbe far perdere dei dati.

      Non teoricamente , la tecnica comunemente nota come delayed allocation e usata in ext4 fino al kernel 2.6.31 non è affatto nuova e provoca perdita di dati nel caso in cui un crash o un panic impediscano al contenuto della cache del filesystem di essere correttamente scritto su disco.

      In particolare il problema è presente anche in xfs , il filesystem sviluppato inizialmente per le ws SGI e portato su linux da prima che ext3 fosse “concepito” e che è un filesystem a 64 bit molto più moderno per design rispetto alla famiglia degli ext*.

      L’ho usato per diverso tempo con soddisfazione ( velocità di accesso sia in scrittura , sia in lettura e capacità di seeking degne di nota ) specie sui file multimediali , almeno fino a quando dopo un crash _non dovuto_ al filesystem , mi sono ritrovato con alcuni file su cui stavo lavorando irrimediabilmente danneggiati , irrecuperabili. ( I backup servono a poco per recuperare le modifiche fatte dopo il backup stesso )

      A dirla tutta il miglior filesystem che abbia mai testato con file multimediali è UDF , si … avete capito bene UDF , il filesystem dei DVD che è insuperabile per capacità di seeking sia in lettura ( visione di un film ) che in scrittura ( editing video ) anche su un harddisk. L’ho abbandonato perchè dopo un crash dovuto a un blackout e a una maledetta batteria di un maledetto UPS , mi sono ritrovato senza alcuna possibilità di successivo accesso alla maledetta partizione. ( *sigh* )

      Per quanto mi riguarda , ho sempre installato i nuovi sistemi su reiserfs ( come ho scelto blowfish o SHA come algoritmo di hash/cifratura delle password al posto di MD5 nelle distribuzioni che mi permettevano di farlo) anche se di volta in volta le opzioni di default ne indicavano altri ( ext2 , ext3 , jfs … )

      Non ho mai perso nulla di significativo con reiserfs ( ad eccezione di qualche file di log ) , persino dopo svariati rebuild-tree.

      Commento di linuser — dicembre 12, 2009 @ 9:31 pm

  10. Tra l’altro stanno lavorando sulla cosa:

    il codice della patch in oggetto:
    http://tinyurl.com/y9on6ob

    il nuovo codice 2.6.32-git9:
    http://tinyurl.com/ydy96bp

    con pesanti modifiche, speriamo bene.

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

  11. […] e sulla presunta inesistenza dei problemi di ext4, riproponendo come articolo, un mio commento in EXT4 continua il calvario, perchè abbia la giusta […]

    Pingback di EXT4: terrosismo mediatico? « Tecnologia e non solo — dicembre 13, 2009 @ 1:16 pm

  12. Correggetemi se dico una cazzata ma io sto usando Ext4 senza il journal, e oltre a velocizzarmi il boot mi risparmio questo scartavetramento di palle che genera il commit. Perché il commit deriva dal journal giusto?

    ovviamente consiglio di farlo a coloro che hanno dischi ssd(sopratutto quelli nei netbook di bassa qualità), perché essi hanno scritture un po’ più limitate dei normali hdd.

    Commento di Santiago — dicembre 13, 2009 @ 7:11 pm

    • No non è il journal che causa il problema ma fdatasync come spiegato nelle info del commit, che appunto forza fsync.

      Da dire anche che i dischi SSD, a differenza dei pendrive USB o schede varie di memoria solida, hanno un firmware che gestisce le scritture distribuendole uniformemente sui vari blocchi, allungando molto la vita del supporto.

      Commento di telperion — dicembre 13, 2009 @ 7:49 pm

  13. a dimenticavo se siete interessati a rimuovere il journaling a Ext4 vi linko la guida che ho fatto apposta.
    http://www.uielinux.org/guide-e-tutorial/2-configurazione/211-ottimizzazioni-ssd-levare-il-journaling-a-ext4.html
    io vi consiglio di leggere la premessa che ho scritto, per non destare polemiche.

    Commento di Santiago — dicembre 13, 2009 @ 7:14 pm

  14. Spero ci voglia meno tempo di quello che mi aspetto ma Btrfs sta salendo la classifica dei filesystem + veloce di quanto ext4 la sta scendendo (o salendo boh ) …
    A features Btrfs vince a tavolino ! poi dalla v.0.18 alla 0.19 c’e’ stato un salto di compatibilità a dimostrare la prematurità del progetto ( ma anche che e’ sotto sviluppo peso in questo momento… dopo 5 anni o cose del generE)
    ciao

    Commento di WonderEnd — dicembre 17, 2009 @ 11:00 am

  15. Venerdì scorso è stato rilasciato il .32.2. Ci sono novità per quanto riguarda Ext4?

    Commento di airport93 — dicembre 22, 2009 @ 12:21 am

    • No, il 2.6.32.2 è uguale al 32.1 per quanto riguarda ext4.

      Commento di telperion — dicembre 22, 2009 @ 9:35 am


RSS feed for comments on this post.

Crea un sito o un blog gratuitamente presso WordPress.com.

%d blogger cliccano Mi Piace per questo: