La notizia:
possibili perdite dati in caso di crash con ext4.
Ma come, ext4 strombazzato “in ogni dove” come il fs che finalmente rinnova quella “lumaca bradiposa imbottita di valium” di ext3, entusiasmo, test, recensioni entusiastiche e poi?
Poi, visto che usa la delayed allocation*, se c’è un crash vi potreste ritrovare, non con i vecchi file senza le modifiche, cosa che “normalmente” ci si aspetterebbe, con una finestra temporale maggiore vista la delayed allocation, no vi potreste ritrovare con i file a zero o troncati.
BELLA MERDA!
Attualmente nonostante gli svariati fs disponibili, solo ext3 con il journaling data=ordered è sicuro, il resto è solo MERDA.
Una patch è programmata per la versione 2.6.30 (!!) del kernel, ancora deve uscire il 29 !!!
Inutile dire che ho provveduto a ripristinare in ext3 i sistemi in uso migrati a ext4, tenendone un paio per test, peccato perchè l’aumento di velocità in scrittura c’era eccome, ma non voglio rischiare che un blackout o un crash mi distrugga il sistema.
Certo che fare test prima di rilasciare come “stabili” queste bombe sarebbe opportuno.
Ancora una volta linux non si smentisce. Come un noto gergo teatrale:
“Tanta merda!!!”
Unitevi tutti al coro:
“ma baff………….”
PS
non venite a scrivere le solite manfrine di alpha beta unstable
che mi arrabbio:
kernel con ext4 e utility di supporto “SONO” stabili.
Info:
blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/
bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45
bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781
Tecnologia e non solo 
Scusa telperion, ma qual’è il punto di questo post?
Che un software rilasciato stabile non deve avere bug ma comunque li ha?
Spero di no. Ci sarebbero ovvietà molto più interessanti da ripetere, credo.
Considerazione: NESSUNA distro Linux usa EXT4 di default. Di conseguenza NESSUN utonto usa questo filesystem. Invece usando il sicurissimo
NESSUN dato è stato perso per colpa di ext4 finora.
Dalle features di fedora 11:
Commento di stefanauss — marzo 17, 2009 @ 2:29 PM
Il senso è esattamente quando scritto.
EXT4 stabile NON è un fs sicuro.
Poteva rimanere devext4 visto che la cosa era nota.
“POSIX fundamentally says that what happens if the system is not shutdown cleanly is undefined. If you want to force things to be stored on disk, you must use fsync() or fdatasync().”
“The final solution, is we need properly written applications and desktop libraries. The proper way of doing this sort of thing is not to have hundreds of tiny files in private ~/.gnome2* and ~/.kde2* directories. Instead, the answer is to use a proper small database like sqllite for application registries, but fixed up so that it allocates and releases space for its database in chunks, and that it uses fdatawrite() instead of fsync() to guarantee that data is written on disk. If sqllite had been properly written so that it grabbed new space for its database storage in chunks of 16k or 64k, and released space when it was no longer needed in similar large chunks via truncate(), and if it used fdatasync() instead of fsync(), the performance problems with FireFox 3 wouldn’t have taken place. Such a solution is also far more efficient in terms of disk space utilization, and minimizes disk writes which is good for SSD’s. It is the ultimate correct answer, but it means that you need someone with Systems experience writing the libraries used by application writers.”
Cioè i dev di gnome e kde per ovviare alla lentezza di ext3 usano metodi NON STANDARD di scrittura al disco, metodi che creano i detti problemi di perdita dati con ext4 e xfs.
Ora visto che è IMPENSABILE riscrivere tutti i de, tanto valeva FARE SUBITO LA PATCH non tra 6 mesi.
“NESSUNA distro Linux usa EXT4 di default”
e chissenefrega, uso tanta roba STABILE che nessuna distro usa di default, cos’è ti deve dire la mamma cosa devi usare?
Pensa che alcune distro di DEFAULT montavano kde4.1 (!!)
Se un sofware viene dichiarato stabile, qualche bug di piccola entità ci stà, ma bug che prevedono possibilità di gravi danni no. Ancora peggio la patch prevista a “babbo morto”
Ora quel è il punto del TUO commento?
Difendere ad oltranza e giustificare ad ogni costo qualsiasi “porcata” avvenga?
Il punto che ext4 DOVEVA restare devext4 ancora per parecchio tempo.
Commento di telperion — marzo 17, 2009 @ 3:02 PM
Allora ho fatto bene a tenermi il mio caro e vecchio ext3 😀
Commento di eDog — marzo 17, 2009 @ 3:05 PM
Anch’io come eDog ho preferito mantenere ext3.
Concordo in pieno con l’articolo, un tempo Linux era il regno del software stabile… ma ext4 come KDE4 ha preso questa brutta abitudine.
Speriamo che altri non seguano questo esempio.
Commento di Bl@ster — marzo 17, 2009 @ 3:14 PM
@Blaster
ext4 come “tale” è sicuro, usato su un server con software che rispettano gli standard posix non crea nessun problema.
I problemi nascono con i DE che non rispettano gli standard.
Insomma si doveva avvisare preventivamente e rilasciare anche una patch.
Tipico esempio di mano destra che non sa cosa fa la sinistra.
Commento di telperion — marzo 17, 2009 @ 3:18 PM
@telperion: Ma se la mettiamo così, un filesystem veloce e con le caratteristiche di ext4, ha molto più motivo d’esistere per il desktop che per i server.
Dunque, concludendo, ext4 ha davvero motivo di esistere?
Commento di Bl@ster — marzo 17, 2009 @ 3:30 PM
@Blaster
ora che sono tornato al “bradipo” ti dico
certo che ha motivo di esistere.
Il punto “nevralgico” è
può uno sviluppatore estraniarsi dal mondo reale e programmare un fs ottimo, che però nel mondo reale, non per colpa dello sviluppatore, ha dei seri problemi, senza prevedere una soluzione?
E può il responsabile del kernel, avallare la cosa senza porre la questione?
E perchè non patcharlo subito o nel 29 invece di aspettare il 30?
Sono domande retoriche.
Nel mondo reale siamo costretti ad usare la “lumaca bradiposa imbottita di valium”
😀
Copia con cp -ax una partizione in un’altra con ext3 e con ext4
e vedi la differenza mentre continui ad usare il DE.
Con ext3 vai al rallentatore con ext4 come se la copia non fosse in corso.
Commento di telperion — marzo 17, 2009 @ 3:44 PM
@Telperion: Ma la questione fondamentale mi pare piuttosto l’ultima. Ext4 ha dei seri problemi? Cavolo, patch a go go da ora, non si deve aspettare la versione .30.
Commento di Bl@ster — marzo 17, 2009 @ 3:48 PM
La questione è più complicata di un semplice bug di EXT4. Le patch non servono per correggere un bug di ext4 ma per far si che i programmi che non utilizzano fsync() non tronchino i file senza riscriverli. È vero che le patch verranno ufficialmente integrate nel 2.6.30 ma per esempio Ubuntu ha le ha già integrate in Jaunty quindi non capisco proprio questo allarmismo.
Uno dovrebbe avere una minima idea di quello che sta scrivendo per non dire cavolate.
Commento di gameover — marzo 17, 2009 @ 7:10 PM
@gameover
Se leggi i commenti 2 e 5 è spiegato esattamente quello che tu dici.
Quanto alle patch di ubuntu dove stanno? Info?
Se ci sono patch sarebbe bene renderle disponibili, mica tutti usano il kernel ubuntu (per fortuna 🙂 ).
Commento di telperion — marzo 17, 2009 @ 7:42 PM
Il paragone con Kde4 ci sta tutto, purtroppo gli utenti/distribuzioni devono rendersi conto che c’è “alpha e alpha” e “stabile e stabile”.
Il filesystem è una di quelle componenti che DEVE essere ultra-stabile per essere usata in produzione.
Commento di grigio — marzo 17, 2009 @ 11:05 PM
Le patch sono quelle nel post https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45 e sono state inserite nel 2.6.28 di Jaunty come da post https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/154 e da post https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/173 .
Dire che EXT4 non è stabile è sbagliato. Il comportamento del fs è quello voluto da design.
Anch’io sono d’accordo nell’avere le patch ma dare tutta la colpa a EXT4 è sbagliato. Per un altro punto di vista della situazione consiglio la lettura di http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ .
Commento di gameover — marzo 17, 2009 @ 11:55 PM
@ Telperion.
Non devo/voglio giustificare i responsabili (e nel caso di questo affaire-ext4, uno se li può addirittura scegliere, i responsabili!), non me ne viene niente. Se ti ho chiesto qual’è il tuo punto, è perchè non l’ho proprio capito. Soprattutto perchè in un rant come questo pieno di MERDA (cit., niente di provocatorio) è difficile afferrarlo. Invece:
"Il punto “nevralgico” èpuò uno sviluppatore estraniarsi dal mondo reale e programmare un fs ottimo, che però nel mondo reale, non per colpa dello sviluppatore, ha dei seri problemi, senza prevedere una soluzione?
E può il responsabile del kernel, avallare la cosa senza porre la questione?
E perchè non patcharlo subito o nel 29 invece di aspettare il 30?
Lo capisco meglio. Limiti miei.
Finite le pubbliche relazioni. Per la patch su Ubuntu, è stato fixato e le patch integrate in Jaunty. Un semestre lampo 😀
Le patch sembrano funzionare (stesse percentuali di perdita dati di ext3 in caso di crash, ossia nulle) ma sembrano anche dare dei peggioramenti alle prestazioni. Proprio il piatto forte di ext4: il mio timore è che con questa patch visto proprio che i DE hanno fanno un mare di I/O su quei file “dotted” interessati dai fix, ext4 si trasformi in un “ext3.5”. A quel punto la domanda “ha ragione di esistere?” sarebbe interessante.
Servono benchmark.
* NTFS usa la delayed allocation (attivabile/disattivabile) da una vita e perde i dati in memoria, non tronca certo i file in caso di crash.Di questa particolare cosa, hai un riferimento? Perchè a me proprio non risultava, ho anche cercato. (E googlando ntfs delayed allocation compari te :D)
L’ovvio riferimento più onnicomprensivo dà risposta negativa:
http://en.wikipedia.org/wiki/Comparison_of_file_systems#Allocation_and_layout_policies
Come hai detto, l’allocation-on-flush è intrinsecamente pericolo (o buggato, punti di vista) tant’è che ne sono afflitti tutti i FS che ne fanno uso. A sto punto non ha senso farci filesystem, per quanto sia prestazionale.
Commento di stefanauss — marzo 18, 2009 @ 4:26 am
E’ da quando uso Linux che vedo queste cose.
La cosa non mi sfiora minimamente, in quanto al fatto che è assolutamente NORMALE che un bug ENORME venga chiuso dopo ANNI.
Io comunque usando EXT4 e KDE4 che scrive un mare di files dotted nella mia home 🙂 sulla mia ultrainstabile Gentoo dove non ce’ un solo pacchetto che sia degno anche solo dell’appellativo “stabile: cosa è che vuoldire?” quando non è robaccia presa da svn o git (si, anche il kernel!) non ho mai perso un solo bit. Tenendo conto che lo uso da Dicembre, tutti i giorni, a me questo fatto sembra soltanto fuffa.
I dischi dati non li ho “migrati” ne “convertiti” ma sono rimasti a EXT3, così come tutte le altre distribuzioni esclusa Gentoo, che giusto perchè fidarsi è bene e non fidarsi è meglio ci rimarranno ancora per lungo lungo tempo.
Quando EXT4 è uscito dalla fase “dev” ed è passato in “stable” con il 28 tutti a fare le corse a chi ce lo ha più duro, poi piangono.
Linux NON possiede roba stabile, nella maggioranza dei casi. Se una roba “sembra che funzioni” esce fuori e tutti la usano. Poi andiamo a additare la Microsoft che non mette WinFS nella nuova versione di Windows, non è che percaso PREFERISCONO provare le cose per ANNI prima di buttarle fuori ? Come bisogna fare per farlo capire alla gente che l’ultima cosa “bleeding edge” NON SI DEVE USARE MAI se non se ne accettano le conseguenze.
Non entro nel merito tecnico specifico del filesystem incriminato, ma se veramente si rivelasse una MERDA (cit.) spero che sia la volta buona che muoiano bruciati vivi qualche migliaia di fanboys inutili che sputano cacca addosso ai sistemi non liberi senza nemmeno averli mai provati.
NTFS, che vi piaccia o nò, è un gran filesystem, molto collaudato e usato in produzioni anche critiche. Certo che se ci andiamo a scrivere sopra con 3G e poi diciamo che non è bono, allora ……
@ Bl@ster: patch a gogò. Ubuntu le ha già. Filesystem non sicuro, Patches di Canonical testate da nessuno tirate fuori a tempo zero, in distro stabile.
Un motivo in più per non usare Ubuntu 😉
Magari le mettono nel .30 per avere tempo di fare le cose per bene e non i “cazzari doppi” per far contenti i frettolosi.
@Telperion: se è per questo una certa distro stabile (non faccio nomi non sta bene lol) monterà i Nouveau di default al posto degli nv. Se è un nuovo utente, ecco come perderlo, al primo colpo. E’ linux, bellezza (cit.)
Commento di LuNa — marzo 18, 2009 @ 7:56 am
KDE4, EXT4, niente da fare il “4” porta SFIGA. 😦
GNOME passerà dalla 3 alla 5 per fregare tutti. 😀
Ho letto questa notizia giorni fa, che dire, avvilente 😥
Ma la cosa peggiore secondo me e che pochi fanno notare è che pure XFS HA QUESTO PROBLEMA. E XFS non è uscito ieri …
Bye Bye Baby al quadrato. Meno male che del DE posso farne a meno nei server.
Commento di Steno — marzo 18, 2009 @ 9:54 am
@Steno
“Bye Bye Baby al quadrato”
facciamo al cubo o alla quinta …
😀
@stefanauss
cache scrittura windows:
se non ricordo male c’è da win98
Sulle patch:
giustamente se torniamo alle performance di ext3, ext4 diventa inutile.
Commento di telperion — marzo 18, 2009 @ 10:49 am
@ Telperion
La cache a cui si riferisce è quella interna degli HD.
Non c’entra assolutamente niente con NTFS e tantomeno con la delayed allocation.
NTFS, che vi piaccia o nò, è un gran filesystem, molto collaudato e usato in produzioni anche critiche.Proprio per questo mi sono molto adirato quando si è rivelato essere l’unico file system dei 4-5 che ho intensivamente usato a perdere dati in seguito a crash. Che mi piaccia o no, mi è andata così.
Patches di Canonical testate da nessuno tirate fuori a tempo zero, in distro stabile.Le patch sono upstream, e non sono in distro stabile. E quando lo sarà, non avrà ext4.
Insomma, tra i millemila motivi per non usare Ubuntu, non ci sarà ext4 😀
Magari le mettono nel .30 per avere tempo di fare le cose per beneA leggere i commenti nel codice delle patch, sembrerebbe proprio così. Si discute ancora sui metodi migliori per quello che si deve fare e cioè, di fatto, forzare il comportamento di ext3 che è quello che si aspettano le apps.
Più che “fuori standard” (GNOME non è più fuori da POSIX di quanto lo siano i software da server), le apps sono ext3-compliant[1]. Il motivo è quello che ha detto Telperion: usare fsync() su ext3 ha un impatto di performance negativo allucinante, proprio perchè il modo ordered di scrivere i dati è *già di suo* come una fsync() forzata. E i DE lo hanno accuratamente evitato.
[1] Gli sviluppatori del kernel sostengono che sia sinonimo di “programmate a cazzo”. Gli sviluppatori rispondono per le rime. 😀
Commento di stefanauss — marzo 18, 2009 @ 3:16 PM
@stefanauss
non dire fesserie, quella è la cache in scrittura del sistema operativo.
La cache dei dischi è piccolissima, in 2-8MB ci starebbe ben poco.
Sul “botta e risposta” non avevo dubbi.
😀
Commento di telperion — marzo 18, 2009 @ 3:59 PM
[…] per come si comportano in scrittura le applicazioni ext3-compliant può causare la perdita di file o troncamenti nei medesimi, in caso di crash o blackout, a causa […]
Pingback di Ancora su EXT4 e possibili perdite dati. « Tecnologia e non solo — marzo 18, 2009 @ 4:32 PM
Ma che significa che ci starebbe poco o no? Il guadagno prestazionale c’è comunque, così come il rischio di perdita dei dati, attivandola, anche su 2-8 Megabyte. Proprio come recita la nota sotto l’opzione.
Comunque: qui
http://support.microsoft.com/?scid=kb%3Ben-us%3B233541&x=13&y=6
puoi leggere:
The Disk Properties Tab “Write Cache Enabled” Feature
If you enable this feature, your computer sends an enable-write-cache command to the hard disk activating the hard disk write-back cache, and if you disable this feature, the hard disk write-back cache is deactivated.
Quella lì non è una delayed allocation. La DA non dipende dalle caratteristiche/funzionalità/settaggi del disco.
NTFS NON ha la delayed allocation.
Le fesserie non rendono migliori i Filesystem. E a me quello interessa.
Commento di stefanauss — marzo 18, 2009 @ 5:03 PM
@stefanauss
http://tuttovolume.blogspot.com/2008/12/velocizzare-windows-vista-abilitando-la.html
Commento di telperion — marzo 18, 2009 @ 6:22 PM
[…] per questo problema e tanti utenti che in rete gridano allo scandalo.Tra questi il mio amico Telperion, persona che stimo e che merita una risposta al suo post in merito al problema, nel quale si […]
Pingback di Cosa vuol dire “stabile” nel mondo Open Source « Guiodic Blog — marzo 18, 2009 @ 6:48 PM
@ telperion
Hai detto che
1) NTFS ha la delayed allocation
2) che la cache in questione non è la cache interna dei dischi.
Il link che hai messo non chiarisce nessuna delle due cose. E’ un HOWTO.
Cosa devo guardare? 😀 Help!
Commento di stefanauss — marzo 18, 2009 @ 7:27 PM
Ecco dopo tanto tempo mi ritrovo sul bel blog
il blog del giullare di corte
i blogger come questo sono i peggiori .
Commento di mapercortesia — marzo 20, 2009 @ 2:00 PM
@mapercortesia
anche i commentatori come te sono estremamente utili con il loro grande contributo di idee e soluzioni.
Maperfavore va … a ciapàirat …
Commento di telperion — marzo 20, 2009 @ 2:05 PM
si vede che non capisci proprio una fava , questo è chiaro, spari cazzate sul tuo blog e neanche ti degni di vedere che la tua notizia è vecchia di secoli.
inoltre pare che non hai proprio provato ext4 che su archlinuz c’è da un po.
non ho mai dico mai perso dati . Sei il compare venuto male di ranzulla ?
ok come volevasi dimostare leggere blog è solo perdita di tempo. Finti guru che scrivono cazzate ecco dopo anni di assenza da wordpress vedo che la situazione non è cambiata
Commento di mapercortesia — marzo 20, 2009 @ 6:03 PM
@mapercortesia
ecco bravo, fai cosi anche tu,
apriti un blog e scrivici su quel che ti pare. che anche per me risponderti (per educazione) è solo perdita di tempo.
Commento di telperion — marzo 20, 2009 @ 6:47 PM
Non ho capito il punto.
Ext4 è stabile, bene.
Le applicazioni sono “ext3-compliant” e non pronte per ext4, bene.
Quindi, finché le applicazioni che usi non saranno aggiornate, non conviene che tu usi ext4. Oppure puoi usarlo ma senza Delayed Allocation, cosa che ottieni montando con l’opzione “-o nodelalloc”. Certo, se il comando mount che usi non riconosce quell’opzione, allora ti conviene aggiornarlo o non usare ext4.
Insomma, uno strumento può essere stabile, ma richiedere modifiche negli strumenti correlati prima di essere utilizzabile a pieno. Io non ci vedo nessuno scandalo. E se alla fine anche venisse fuori che ext4 non è un filesystem adatto ai sistemi desktop, questo non vorrà dire che sia un filesystem instabile, sbagliato o inutile. No?
Commento di Marco — Maggio 21, 2009 @ 9:45 am
Se prima me lo dici in maniera chiara, posso essere anche d’accordo con te.
Se me lo vendi come la panacea della lentezza di ext3 e poi da un sacco di problemi di perdita file, allora io mi incavolo.
Comunque con i kernel 2.6.30-rcx sembra che sia a posto, quindi un’analisi più attenta del mondo “reale” avrebbe evitato tutto il casino e l’ennesima “figuraccia”.
Si figuraccia.
Commento di telperion — Maggio 21, 2009 @ 4:29 PM