di  -  mercoledì 1 aprile 2009

Non avendo mai avuto un lettore di floppy per il mio amato Commodore 128, la prima occasione per lavorare seriamente coi filesystem è stata quella con l’Amiga (che tra l’altro ai tempi aveva già un comodissimo sistema di tipo plug & play per montare e smontare a piacimento nuovi filesystem “a caldo”, senza mai riavviare la macchina).

Da lì in poi è venuto fuori il tipico problema dovuto al classico black-out o sbalzo di tensione (verificatisi immancabilmente proprio mentre stavo scrivendo un file su disco): la corruzione o, peggio ancora, la perdita dei dati.

E’ fuor di dubbio che di fronte a fenomeni come questi e senza un gruppo di continuità è praticamente impossibile aspettarsi che non sia successo qualcosa ai dati. Anche se abbiamo superato il tempo dei floppy e abbiamo gli hard disk, questi ultimi sono quasi sempre in movimento (mentre con AmigaOS lo erano soltanto “a comando”, a seguito di precise azioni dell’utente) e spesso in scrittura, dunque non è raro che capiti qualcosa di spiacevole, com’è avvenuto di recente con l’ultima versione del più diffuso filesystem di Linux, EXT, ma… senza blackout!

Ne ha parlato di recente un programmatore su un apposito bug track che è stato aperto per mettere a conoscenza la comunità dell’esistenza di questo problema che ha implicazioni molto importanti, visto che, appunto, provoca la perdita dei dati. E qui, come ho già detto, non possiamo dare la colpa alla solita società che ci fornisce l’energia elettrica, visto che si verifica anche con la macchina perennemente accesa, e magari ben protetta da un gruppo di continuità.

E’ evidente che la causa vada ricercata nella struttura del filesystem oppure nella sua implementazione. Nel primo caso questi potrebbe non integrare appositi meccanismi per la salvaguardia delle informazioni e/o il ripristino da condizioni nefaste come la mancanza di corrente. Ma non ricadiamo in tali condizioni estreme, quindi è l’implementazione a essere difettosa o, magari, proprio voluta così.

A quanto pare è esattamente in questo modo che sono andate le cose: gli implementatori hanno pensato bene di utilizzare una pratica che sembra comune ai filesystem più moderni, chiamata delayed allocation (allocazione posticipata), per cui i dati scritti dall’applicazione (per la precisione nella modalità di append, quindi scrivendo sempre alla fine del file) rimangono esclusivamente in memoria, e i blocchi (o cluster) da allocare vengono soltanto sottratti dal numero totale di blocchi liberi, senza riservarli immediatamente.

Quindi le informazioni rimaste in memoria lo rimarranno finché il sistema operativo non deciderà finalmente di scriverli effettuando ogni tanto il cosidetto flush dei dati, che consiste appunto nello scrivere quelli che finora erano rimasti in memoria ed essere in perfetta sincronia col dispositivo di massa. Il problema è che, con gli esempi evidenziati nel link, ciò provoca una perdita dei dati se non si forza manualmente il loro flush utilizzando un’apposita API (fsync) del s.o..

In buona sostanza l’autore dell’articolo ha deciso di scaricare la colpa ai programmatori che non sono abbastanza “attenti” nello scrivere i loro programmi. Ma subito dopo si lamenta che l’invocazione della fsync ha un forte impatto (negativo, ovviamente) sulle prestazioni (e ciò è indubbiamente vero)!

A questo punto rivolge le sue invettive sugli (sempre scarsi ovviamente) programmatori che scrivono miriadi di piccoli file, e che forzando l’fsync per ogni file metterebbero in ginocchio il sistema. A parte lo scenario improbabile (scrivere centinaia di piccoli file nello stesso momento mi pare poco realistico), ho l’impressione che si tratti di una persona che non è mai soddisfatta del lavoro degli altri, ma soprattutto che guarda soltanto al lavoro degli altri, ma non a quello dei programmatori di sistema.

Come programmatore ho un’opinione diversa dalla sua. Per quanto mi riguarda io ho “stipulato un contratto” col s.o., e tale contratto è rappresentato dalle API. Una volta chiuso il file, anche senza aver mai usato la fsync, e senza che il s.o. abbia sollevato eccezioni (dandomi, quindi, l’OK), il mio lavoro è finito e il s.o. ha in mano tutte le informazioni necessarie per gestire correttamente anche questi casi.

Questo perché io non posso sapere in alcun modo che fine farà il file e i dati che conteneva, una volta che l’ho chiuso. In nessun modo. E nemmeno mi deve interessare saperlo: il mio lavoro l’ho portato a termine e non me ne devo più preoccupare.

A questo punto, visto che i problemi dovuti all’allocazione posticipata sono ben noti e, soprattutto, ampiamente prevedibili, dev’essere il filesystem (mi riferisco all’implementazione, cioé al codice) a intercettarli e a prendere le dovute iniziative atte a garantire la giusta sequenziazione delle scritture dei dati.

Per me non ha senso né che un filesystem adotti politiche che possono provocare perdite di dati a fronte di incrementi prestazionali, ma nemmeno costringere gli sviluppatori a utilizzare sempre la fsync che le fa decadere troppo e sempre. I conflitti vengano risolti da chi di competenza, ma soprattutto dall’unico ente che è in grado di rilevarli e risolverli, azzerando le perdite dei dati e limitando le prestazioni esclusivamente nel momento in cui si verificano (cosa impossibile per una normale applicazione).

Questo ovviamente complicherebbe l’implementazione, ma garantirebbe il miglior compromesso prestazionale possibile, salvaguardando sempre e comunque l’integrità dei dati, che ricordo essere l’obiettivo più importante per questo delicatissimo componente del s.o. (infatti è fra i software che richiedono più tempo e risorse per andare in produzione, a causa del numero di attenzioni e test notevolmente più elevato rispetto alle altre componenti; probabilmente il solo kernel richiede molte più attenzioni).

Altra cosa, nel link, come già detto, si afferma che tutti i filesystem moderni fanno uso dell’allocazione ritardata e, quindi, sono soggetti agli stessi problemi. Da una rapida ricerca sembra, invece, che siano soltanto cinque: HFS+, XFS, Reiser4, ZFS ed ext4.

Questo, lo ribadisco se non fosse chiaro, è il mio personalissimo punto di vista sulla faccenda e sull’argomento filesystem e integrità dei dati. E vale ovviamente anche per i database, che hanno problematiche simili, anche se a scala più ridotta (si occupano di singoli archivi/file; i filesystem, invece, di tutti i file in esso contenuti, quindi anche di eventuali database).

Visto che oggi c’è una varietà di filesystem a disposizione e sufficiente libertà di scelta, il mio consiglio è di vagliare attentamente quale soluzione adottare per l’archiviazione dei nostri contenuti. Ricordate: gli stiamo affidando i nostri dati. E io ci tengo a che non si perdano.

91 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Filippo
     scrive: 

    Dire che ext4 è il più diffuso file system per linux mi sembra una forzatura. Al momento attuale credo che ext3 sia molto più diffuso di ext4.

  • # 2
    Cesare Di Mauro
     scrive: 

    Scusami, dovevo scrivere soltanto EXT e non EXT4: lapsus freudiano.

    Infatti avevo scritto “l’ultima versione del più diffuso filesystem di Linux”.

    Grazie per la segnalazione. Correggo subito. :)

  • # 3
    Mister24
     scrive: 

    Sembra che una patch per il kernel che risolve questo bug sia già stata fatta e verrà rilasciata nella versione 2.6.30.
    Mandriva l’ha già inclusa nel 2.6.29 che sarà il kernel di default nella 2009.1.
    Non so come risolva la situazione, se ad esempio diminuisce il tempo della delayed allocation

  • # 4
    Cesare Di Mauro
     scrive: 

    Da quel che ho capito, non dovrebbe essere una falla del kernel (che dovrebbe avere un’interfaccia generica per qualunque filesystem), quanto del codice dello specifico EXT4.

    Strano che adesso si parli di una patch del kernel. Vedremo se arriveranno altre informazioni più precise in merito.

  • # 5
    Sig. Stroboscopico
     scrive: 

    Sarebbe interessante sapere a quanto ammonta esattamente questa percentuale di errore e quanto rispetto, per esempio, all’uso di memorie non ECC.
    Un0altra tragedia sono anche i cd/dvd e la loro durata di vita… quanto backup persi…

    Ma nell’articolo linkato non spiega che non è il file system a corrompere il dato di per se ma l’applicazione?

    “The file system is not “truncating” files. The application is truncating the files, or is constantly overwriting the files using the rename system call. This is a fundamentally unsafe thing to do, and ext3 just happened to paper things over. But *both* XFS and ext4 does delayed allocation, which means that data blocks don’t get allocated right away, and they don’t get written right away. Btrfs will be doing delayed allocation as well; all modern filesystems will do this, because it’s how you get better performance. Applications are expected to use fsync() or fdatasync(), and if that impacts their performance too much, to use a single berkdb or other binary database file, and not do something stupid with hundreds of tiny text files that only hold a few bytes of data in each text file.”

    Veramente molto interessante l’argomento!

    Ciao

  • # 6
    Cesare Di Mauro
     scrive: 

    Non è che non lo spiega: dà una sua opinabilissima motivazione (scarica la colpa soltanto sull’applicazione), che da programmatore (lo sono anch’io :D) non condivido assolutamente.

    Non è l’applicazione a creare problemi. Quando un’applicazione ha chiuso il file e il s.o. gli ha detto “ok, è tutto a posto”, togliendogli anche il lock sull’handle/i-node, a questo tutto rimane nelle sue mani (l’applicazione non può fare più nulla: ha “ceduto le armi”).

    Se a questo punto (quindi dopo la chiusura) si fa un’altra operazione sullo stesso file (vedi il rename degli esempi), è solo il file system che può rispondere di eventuali disastri che succederebbero a causa di una non corretta sequenziazione dei dati relativi al file in questione.

    Questa è la mia opinione ovviamente, eh!

    P.S. Grazie per i complimenti. :)

  • # 7
    OeCrE
     scrive: 

    “Come programmatore ho un’opinione diversa dalla sua.”
    ..ed io dalla tua ;-)..
    “Per quanto mi riguarda io ho “stipulato un contratto” col s.o., e tale contratto è rappresentato dalle API.”…”il mio lavoro è finito e il s.o. ha in mano tutte le informazioni necessarie per gestire correttamente anche questi casi” A parte gli scherzi, le tue idee sono condivisibili, ma al momento attuale quando hai a che fare con prodotti di terzi – cioè sempre – (O.S. ma anche servizi vari di altre applicazioni/sistemi) non c’è contratto che tenga. La “roba” deve andare, non ci sono santi. Il nostro lavoro è fatto di “truschi”. Il 15% di lavoro si spende nel produrre qualcosa ed il restante per farlo andare/parlare/interagire con il suo ambiente. Ambiente che non è MAI secondo specifica, che non ha MAI quell’API che serve, che non ha MAI le prestazioni promesse e che soprattutto non funziona MAI. Se facessimo valere tutti i “contratti” non girerebbe mai nulla… è triste ma è vero.

  • # 8
    Cesare Di Mauro
     scrive: 

    Proprio le API sono le basi: se mancano quelle, abbiamo finito. Passi per eventuali bug, di cui non possiamo fare a meno, che ovviamente si possono sempre correggere.

    Ma qui un’applicazione non ha la più pallida idea di cosa facciano “dietro le spalle” filesystem e sistema operativo.

    Un’applicazione (e il programmatore in primis :D) non è tenuta a sapere che qualcuno ha deciso di punto in bianco di utilizzare l’allocazione posticipata, e che questo le creerà problemi coi dati che manipola.

  • # 9
    Banjo
     scrive: 

    Da pivello in materia, posso dire solo che in tema Pc avevo una forte antipatia per il filesystem FAT, in tutte le sue versioni, e quindi ho salutato con un alleluja l’avvento del più sicuro NTFS.

  • # 10
    zephyr83
     scrive: 

    Scusate, nn sn molto pratico ma io nn capisco a quale conclusione si arriva in questo “articolo”:
    “Per me non ha senso né che un filesystem adotti politiche che possono provocare perdite di dati a fronte di incrementi prestazionali, ma nemmeno costringere gli sviluppatori a utilizzare sempre la fsync che le fa decadere troppo e sempre.”
    quindi? la soluzione qual è? chi si deve occupare di questa cosa? il sistema operativo? e come?
    “I conflitti vengano risolti da chi di competenza, ma soprattutto dall’unico ente che è in grado di rilevarli e risolverli,”
    Nn basta usare altri file system tipo ntfs o reiserfs?

  • # 11
    Alberto
     scrive: 

    Mai perso un bit con ZFS e UFS2 anche se ovviamente e’ sempre possibile che passi qualcuno e ti scavalli il cavo di alimentazione prima che la macchina riesca a fare il flush dei dati. Ad ogni modo su macchine BSD si tolgono le softupdate e le scritture sono sincrone.. Andando piu’ a fondo nel problema. :) come la mette il tipo con le delayed write applicate dai controller? :D si perche’ anche quelli non sono sincroni.
    Infatti in ambito enterprise hanno memorie tampone dotate di batteria.

  • # 12
    Cesare Di Mauro
     scrive: 

    @Banjo: perfettamente d’accordo. FAT era un buon filesystem quando è nato e fino alla versione 16 era decente. FAT32 per quanto mi riguarda andava e va bene solo per le chiavette USB.

    @zephyr83. La soluzione corretta (sempre a mio avviso) è che si debba occupare l’implementazione del filesystem di questi problemi, perché sono da lei causati. Al limite col supporto del kernel, se necessario (il caching in memoria dei blocchi dei dati mi sembra sia di sua competenza).

    Come si realizza? Le modalità con cui si verificano questi problemi sono ben note proprio perché è l’implementazione a essere stata realizzata in questo modo.
    A questo punto è sufficiente aggiungere un controllo per i conflitti e soltanto in questo caso forzare il flush dei blocchi di dati prima dell’orario normalmente programmato dal s.o..
    In questo modo verrà garantito che i dati vengano scritti nel giusto ordine sul disco prima che si creino sovrapposizioni che portano a queste perdite.

    Questo per chi sviluppa i filesystem.

    Per rispondere all’ultima domanda, chiaro che sì. Infatti è quello il mio consiglio, ma per l’utente finale, che non ha gioco sulle scelte (azzardate in questo caso) degli sviluppatori dei filesystem.

    Spero di essere stato chiaro. Eventualmente sono disponibile ad altre spiegazioni.

  • # 13
    Cesare Di Mauro
     scrive: 

    @Alberto: con ZFS è documentato sia possibile avere problemi di questo tipo. Ovviamente trovandosi nelle precise condizioni.

    Altri s.o. Unix-like non presentano gli stessi problemi, come hai giustamente rilevato (anche qui, c’è un bug famoso su Linux sullo stesso tema che su altri s.o. Unix-Like non è presente; magari ne riparlo qualche altra volta).

    Personalmente ritengo una “delayed write” meno pericolosa di una “delayed allocation” che ti alloca blocchi senza neppure marcarli come tali.

    Fermo restando che è sicuramente fonte di altri problemi, ci mancherebbe. Ma se non erro si tratta di impostazioni modificabili.

    Anche qui, un’applicazione rimane sempre e comunque “agnostica” da questo punto di vista: non sa né è tenuta a sapere di queste politiche troppo aggressive e potenzialmente pericolose.

    Intanto fa la brava il suo dovere usando le API come da specifiche. Per il resto… incrocia le dita, viste le prospettive poco allegre che ci sono. :D

  • # 14
    Alberto
     scrive: 

    Cesare.. Ovviamente l’applicazione deve essere agnostica rispetto al FS, cheglienedeve fregare ad un applicativo come i file vengano allocati e scritti, mi sembra lapalissiano. L’incertezza deve rimanere fino a che l’FD e’ aperto.. ma una volta chiuso mi aspetto che il FS lo abbia reso consistente sul disco. Spesso questo non accade, ma ripeto concordo con te che deve essere il s.o. a gestirsela. Oppure deve essere oggetto di analisi da parte del sistemista. Visto che io faccio quel mestiere del caxxo chiamato sistemista/programmatore mi trovo nel mezzo del guado. Se in fase di definizione di un architettura viene rilevata l’esigenza di dati sempre coerenti in tutte le condizioni (in ambito bancario ad esempio) allora si adottano le soluzioni per garantirlo a scapito anche delle performance.

  • # 15
    zephyr83
     scrive: 

    Grazie Cesare per il chiarimento quindi ne approfitto :) oltre al file system chi “altro” interviene in questi processori di scrittura? faccio questa domanda perché noto fra windows e linux delle differenze evidenti anche usando lo stesso file system (fat32, ntfs, etx3) in particolare quando scrivo su una chiavetta o scheda di memoria: cn windows praticamente nn ho mai avuto perdita di dati togliendo la chiavetta senza fare una rimozione sicura mentre con linux mi è capitato e anche spesso! è una cosa che ho notato con più distro (ubuntu, frugalware, debian, semrpe tutte con kde). mi sembra un “problema” spiegabile cn quanto detto in questo articolo e nei commenti quindi nn dipenderebbe solo dal file system.
    Inoltre il journaling non dovrebbe aiutare in questo? cioè nn è stato pensato proprio per questo?

  • # 16
    sirus
     scrive: 

    Per quanto mi riguarda io ho “stipulato un contratto” col s.o., e tale contratto è rappresentato dalle API. Una volta chiuso il file, anche senza aver mai usato la fsync, e senza che il s.o. abbia sollevato eccezioni (dandomi, quindi, l’OK), il mio lavoro è finito e il s.o. ha in mano tutte le informazioni necessarie per gestire correttamente anche questi casi.

    Il problema è proprio qui, considerando che stiamo parlando di sistemi operativi che rispettano lo standard POSIX, il contratto che hai stipulato non prevede quello di cui parli. Al contrario, lo standard POSIX consiglia l’utilizzo di fsync().
    Ext3 per una serie di motivi (non necessariamente legati al delayed allocation) permetteva di ridurre al minimo questi problemi (probabilità quasi nulla nella maggior parte delle situazioni) ma questo comportamento non è quello definito dallo standard.

    È stato giustamente fatto notare come fsync() sia piuttosto lenta, questo è dovuto all’implementazione di Ext3 che per ogni chiamata effettua il flush di tutti i file e non solo del file su cui viene invocata; l’esecuzione di fsync() su Ext4 è molto più performante.

    L’autore del commento sul bug (che è anche uno degli sviluppatori di Ext4, quindi è ovvio che tenti di portare acqua al suo mulino) ha lo standard POSIX dalla sua parte, quindi mi sento di dargli ragione.

  • # 17
    massimo m.
     scrive: 

    sono d’accordo con cesare.
    non ci sono “trucchi” che tengano.
    anche io sono stato programmatore, ma i “trucchi” non li ho mai usati, e mai li usero’, perche’ sei sicuro che prima o poi ci sbatti il muso, e rendono il programma meno elegante, leggibile e chiaro.
    li’ la cazzata l’hanno fatta gli sviluppatori del kernel linux. se cambi una cosa, devi controllare che sia compatibile con il passato.

    e sono anche d’accordo sul fatto che una volta chiuso il file, e’ compito del so far andare tutto bene. l’applicativo non ha e non deve assolutamente avere il compito di andare a sindacare cosa fa o no il so.
    gia’ molti so vietano all’applicativo di pasticciare a basso livello con i dischi (perche’ ci deve essere sempre di mezzo il so a controllare che l’applicazione non faccia casini), quindi e’ evidente che il so deve occuparsi di tutto cio’ che non e’ compito dello sviluppatore.

  • # 18
    Cesare Di Mauro
     scrive: 

    @Alberto: scusami, allora non avevo capito io (e può essere, visto che sono con la febbre da 5 giorni :D).

    Sono d’accordo con te, ma aggiungo che un buon s.o. dovrebbe mettere alla sua base l’integrità dei dati e la loro coerenza.

    Per lo meno s.o. “mainstream” (se mi passi il termine), perché su soluzioni custom che hanno precisi requisiti è ovvio che le specifiche del rapporto s.o. applicazione le fa il team che deve affrontare il problema, e può decidere di dar priorità alle prestazioni piuttosto che alla validità dei dati.

    @zephyr83: nell’articolo ne avevo accennato, ma mi rendo conto che è molto meglio chiarire come stanno le cose quando si parla di filesystem.

    Quando noi formattiamo una partizione, una chiavetta USB, o altro usualmente scegliamo (a volte implicitamente perché già selezionata fra le voci) il tipo di filesystem, cioé la struttura dati che verrà utilizzata per immagazzinare le informazioni.

    Queste sono logicamente divise nei dati veri e propri (chiamati “contenuto” del file: ciò che fisicamente interessa all’utente), i loro attributi (es: nome del file, data di creazione, perfino la dimensione del contenuto: sono tutti “metadati” associati a un preciso contenuto), e infine i dati “privati” del filesystem che deve dare un certo “ordine” al tutto.

    Questo è ciò che otterrai scegliendo un certo filesystem piuttosto che un altro: una ben precisa struttura che assumerà lo spazio che hai selezionato.

    Per gestire il tutto serve, però, un software, e questa è quella che ho sempre chiamato “implementazione del filesystem”. Cioé io domattina mi alzo e decido di scrivere un programma che gestire una partizione FAT32.
    Posto che sarà sicuramente effetto dei deliri febbrili (c’è un bel po’ di lavoro dietro a un filesystem, te l’assicuro), avrò tirato l’n-esimo codice che sulla carta dovrebbe fare la stessa cosa.

    E qui arrivano i problemi, che giustamente hai riportato (e non sei il solo a esserci passato: purtroppo è un problema molto comune). Già, perché l’implementazione potrebbe non seguire fedelmente le specifiche o, caso più normale per un programmatore che ci sbatte la testa tutti i santi giorni, essere semplicemente bacata.

    Questo è “l’origine di tutti i mali”. E nel secondo caso io non ho nulla da dire: i bug sono una componente intrinseca del software. Ma sicuramente se mi metto a fare un filesystem devo assolutamente spendere molto, ma molto più tempo per la fase di testing.

    Ragazzi, lo dicevo nell’articolo, noi affidiamo al filesystem i nostri dati. E una implementazione del filesystem che li perde a causa di una leggerezza dei progettisti (che non si sono attenuti rigorosamente alle specifiche) o per aver risparmiato sulla fase di test lo trovo inaccettabile da dei programmatori professionisti.

    Immagina cosa succederebbe se i progettisti di un peacemaker fossero così poco accorti. Peggio ancora per chi realizza software per il controllo del nocciolo di una centrale nucleare.

    Su certe cose non si transige: non si può giocare o buttarsi sul risparmio.

    Fino sul journaling. Questo non dipende dall’implementazione, ma dalla struttura del filesystem. Dev’essere quest’ultima a prevederlo e definire in maniera precisa il suo funzionamento.

    Posto che un filesystem senza journaling oggi è decisamente obsoleto e utile soltanto le chiavette USB, nel caso in cui questa funzionalità sia presente ovviamente va implementata in maniera corretta come ho ho già spiegato prima.

    Spero di aver chiarito i tuoi dubbi. Eventualmente chiedi pure (se sono ancora vivo proverò a risponderti :D ).

    @sirus: mi spiace, ma da quello che dici allora la situazione è ancora più grave del previsto, perché questo signore ignora sia il valore di un filesystem e le finalità per cui nasce (vedi la mia dissertazione sull’argomento poco sopra) sia lo standard POSIX che hai citato.

    Ecco qui: http://www.opengroup.org/onlinepubs/000095399/functions/fclose.html

    The fclose() function shall cause the stream pointed to by stream to be flushed and the associated file to be closed. Any unwritten buffered data for the stream shall be written to the file; any unread buffered data shall be discarded. Whether or not the call succeeds, the stream shall be disassociated from the file and any buffer set by the setbuf() or setvbuf() function shall be disassociated from the stream. If the associated buffer was automatically allocated, it shall be deallocated.

    Mi sono permesso di sottolineare la parte che interessa il nostro discorso: direi che c’è ben poco da “interpretare”, non trovi? Mi sembra sia chiaro: con la close i dati non ancora scritti vanno trasferiti su file. Senza né se né ma. Per cui la fsync prima della close io NON la piazzo perché deve sbrigarsela il filesystem.

    E non potrebbe essere così, se ci pensi bene. Vedi anche l’ultimo messaggio di Alberto: certe cose per un sistemista e/o programmatore professionista che ha ben chiaro il concetto di filesystem sono a dir poco ovvie.

    Una sola cosa mi sento dire, dopo che mi hai detto che quello è uno sviluppatore di EXT4: in che mani ingenue e ignoranti ci si affida.

    Sia chiaro: non ce l’ho con te, ma commento la faccenda e le parole di questo tizio. Anzi, ti ringrazio per avermi fatto sapere chi è.

  • # 19
    Cesare Di Mauro
     scrive: 

    @massimo m.: ti ringrazio e ovviamente non posso che condividere ciò che hai detto.

    A scanso di equivoci, il mio giudizio sarebbe ugualmente lapidario nei confronti di qualunque sviluppatore avesse avuto così poca accortezza nell’implementare un filesystem.

    Sono un professionista, e sulle basi non transigo: si devono far rispettare.

    Poi il bug allucinante che si manifesta quando la Luna è in perielio in un anno bisistile lo posso anche accettare, perché da coder so che è impossibile garantire l’assenza dei bug.

    Ma mi aspetto che, una volta individuato, lo si corregga di corsa e si rilasciano il prima possibile la patch (posto che abbia passato TUTTI i severissimi test, ovviamente).

  • # 20
    zephyr83
     scrive: 

    Grazie Cesare ora è tutto un po’ più chiaro! Ignoravo questa questione….o almeno in linea di principio sapevo della possibilità di perdita di dati in caso di mancanza di corrente ma con l’utilizzo di file system con journaling era stata ridotta molto! Diciamo che leggendo questo articolo viene un po’ il “panico”, sembra che sia una cosa che avviene non tanto raramente ma penso sia un problema che riguada marginalmente il mondo “consumer”. Discorso diversissimo invece in altri ambiti dove questo problema nn dovrebbe mai presentarsi!
    Cmq su linux aspetterò ad adottare ext4 e continuerò con reiserfs che finora mi è sempre andato benissimo

  • # 21
    samuele
     scrive: 

    scusate, ma io ho trovato questo… non so se centra ( non sono un programmatore)

    int fclose(FILE *fp);
    Description
    The fclose() function will flush the stream pointed to by fp (writing any buffered output data using fflush(3)) and close the underlying file descriptor.

    ma nelle note:

    Note that fclose() only flushes the user space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, e.g. with sync(2) or fsync(2).

    saluti

    trovato qui:
    http://linux.die.net/man/3/fclose

  • # 22
    sirus
     scrive: 

    @ Cesare Di Mauro
    Tu hai giustamente citato la chiamata fclose() ma se noti negli esempi riportati sul bug tracker fanno uso della chiamata close() che non garantisce quello che hai sottolineato nel tuo post.
    È anche possibile che fclose() e close() si comportino in modo differente, o meglio, che fclose() garantisca qualche cosa di più rispetto a close().

    Qui http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ puoi trovare un post della persona di cui stiamo parlando.

  • # 23
    Ciano
     scrive: 

    Questo mi sembra più un problema di gestione della consistenza del buffer da parte del driver del filesystem.
    Se chiamando una Rename() subito dopo la chiusura di un file e rischio di perdermi le modifiche fatte, significa che qualquno ha fatto una grossa cazzata nella scrittura del codice.
    La chiamata di una API (in questo caso la Rename()), deve causare una serie di eventi per assicurare la consistenza dei dati, indipendentemente dalle scelte di gestione del buffer di scrittura/lettura.
    Per esempio una Rename() dovrebbe o scatenare un flush dei dati, oppure il comando deve essere accodato in modo da lavorare su dati consistenti e non direttamente su disco, quando sai che potresti avere un buffer non scritto.
    A mio modo di vedere l’uso di una Flush() deve servire per sapere con certezza che il file è stato scritto sul device, perche’ nel frattempo la chiavetta potrebbe essere stata tolta o la rete non essere più disponibile.

  • # 24
    Ciano
     scrive: 

    Ho letto ora il commento di sirus, per gli esempi riportati bisognerebbe verificare le differenze tra fclose() e close().

  • # 25
    Andrea R
     scrive: 

    infatti nessuna distro usa ext4 in maniera predefinita al momento. Te lo mettono lì per completezza, per favorire il testing.
    Proprio perchè tutti “mettono al primo posto l’integrità dei dati”. Chi è che ha mai detto che ext4 è sicuro e può essere usato tranquillamente per tutto?

    Mi pare chiaro che un baco nel filesytem porti a perdite di dati e un filesystem nuovo abbia bachi.
    Poi ti dico, è talmente più veloce degli altri che io sto valutando di usarlo lo stesso, almeno per la root.

    Mi piacerebbe capire se di certe cose si parla solo per parlarne male da queste parti. “ext4″ come ricerca non torna altri risultati significativi, quindi direi di sì.
    Volete altre “notizie” come questa? Perchè è pieno di bachi GNU/Linux e tutti i giorni l’utilizzo può presentare qualche seccatura, ma almeno ci lascia la coscienza pulita.

  • # 26
    Cesare Di Mauro
     scrive: 

    @samuele: infatti il problema non è dell’applicazione, che utilizza un piccolo buffer (generalmente di 128 byte, se non ricordo male) per minimizzare il più possibile le chiamate al kernel per qualunque operazione di lettura / scrittura.

    Mi spiego meglio dopo, rispondendo a sirus.

    @sirus: hai perfettamente ragione quando affermi che fclose fa qualcosina in più, perché le API della serie f* sono state introdotte per le motivazioni di cui parlo qui sopra, e possiamo definirle un’estensione di quelle “base”.

    Il “di più” della fclose, però, finisce con la gestione del suo piccolo buffer interno. Per il resto viene fatto uso delle API “tradizionali”.

    Infatti sempre dal link della fclose che ho fornito prima, ti riporto una frase che chiarisce la relazione fra fclose e close:

    The fclose() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream pointed to by stream.

    Quindi fclose si deve comportare esattamente come la close.

    Che significa questo? Che per annullare la differenza fra una fclose e una close è sufficiente questo pezzo di codice:
    fflush(f);
    fclose(f);

    Una volta che la fflush ha svuotato il suo piccolo buffer, una successiva chiamata a fclose comporta né più né meno di una chiamata a close. Perché continua a rimanere soltanto questa la differenza fra le due API: la gestione di un piccolo buffer interno che la fclose fa in più rispetto alla close.

    Mentre il problema di cui stiamo parlando riguarda il kernel space, e infatti il messaggio di samuele è piuttosto eloquente: per assicurarsi che i dati vengano effettivamente scritti, devono essere svuotati i buffer del kernel.

    Il che richiede, appunto, l’uso della famigerata fsync (o sync per la versione sui FD), che è al centro dei problemi e che opera… con questi buffer innaccessibili a livello applicativo (se non indirettamente).

    Infine, l’ultima frase del pezzo che ho riportato evidenza in maniera inequivocabile la relazione fra fclose e close: la prima utilizza un file descriptor. E i FD sono gli oggetti che manipolano le API non f* (open, close, ecc.).

    Spero di essere stato chiaro.

  • # 27
    Cesare Di Mauro
     scrive: 

    @Andrea R: la mia coscienza è pulita nella misura in cui faccio corretta informazione e metto a conoscenza i miei lettori di problemi tecnici come questi.

    Se così non è, ti pregherei di evidenziare quale parte dell’articolo ritieni non corretta e come dovrebbe essere.

    Grazie

  • # 28
    Ciano
     scrive: 

    Non volevo generare un flame contro linux (che non uso).
    Ma volevo piuttosto criticare questo tipo di bug che non è solo un errore di scrittura del codice ma piuttosto un bug by design (o una feature come direbbero in microsoft :) ).
    Ho letto tra i commenti del blog di “Theodore Ts’o” che hanno già in cantiere 3 patch, che cambiano il comportamento di alcune API attivando un flush dei blocchi del file e rendendole più atomiche prima di fare altre modifiche, anche andando contro alle specifiche POSIX.
    Inoltre qualquno critica le specifiche POSIX da questo punto di vista perchè non garantiscono la consistenza dei file.
    Secondo me dovrebbero pensare più alla struttura ACID quando progettano un filesystem.

  • # 29
    Francesco
     scrive: 

    Mah, con che presunzione certa gente crede di saperne di più degli sviluppatori di un kernel o di un filesystem io non lo so… e neanche che gli venisse il dubbio di andare a informarsi meglio…
    Ecco le specifiche ufficiali del C99 e della libreria standard: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
    Qui si dice chiaramente che “A successful call to the fclose function causes the stream pointed to by stream to be
    flushed and the associated file to be closed. Any unwritten buffered data for the stream ***are delivered to the host environment to be written to the file***”. Il che NON significa che il file verrà scritto immediatamente su disco, ma che il sistema operativo deciderà il momento più opportuno per farlo.
    fsync esiste appunto per assicurare che il file sia effettivamente scritto.

    Altra fonte: Linux System Programming
    http://books.google.it/books?id=k_ocKY0iegsC&printsec=frontcover&dq=linux+system+programming#PPA41,M1

    close():
    Note that ***closing a file has no bearing on when the file is flushed to disk.*** If an application wants to ensure that the file is committed to disk before closing it, it needs to make use of one of the synchronization options discussed earlier in “Synchronized I/O.”

    fclose():
    Any buffered and not-yet-written data is first ***flushed***. On success, fclose() returns 0. On failure, it returns EOF and sets errno appropriately.

    Cosa significa flush in questo caso?
    fflush() merely writes the user-buffered data out to the kernel buffer. The effect is the same as if user buffering was not employed, and write() was used directly. ***It does not guarantee that the data is physically committed to any medium—for that need, use something like fsync() (see “Synchronized I/O” in Chapter 2).*** Most likely, you will want to call fflush(), followed immediately by fsync(): that is, first ensure that the user buffer is written out to the kernel, and then ensure that the kernel’s buffer is written out to disk.

    In conclusione i programmatori di applicazioni, per ignoranza, facendo assunzioni sbagliate, scrivono codice sbagliato. Punto.
    Io uso l’ext4 da ANNI ormai, da quando è stato introdotto per la prima volta come sperimentale nel kernel, e prima che il formato su disco si fosse stabilizzato. Chiamatemi pazzo ma non ho MAI e dico MAI avuto perdite di dati di sorta, nonostante avrei tranquillamente potuto sperimentarne. Sono rimasto strabiliato dalla bontà dello sviluppo di questo filesystem. E evidentemente qui chi parla male di questo filesystem non l’ha mai provato. Tra l’altro se tutti i filesystem menzionati supportano la delayed allocation e il problema sia venuto a galla solo ora significa che è molto ma molto difficile che si verifichi, dato che i filesystem menzionati (soprattutto XFS) esistono da molto più tempo e sono molto più usati di ext4.
    Qui si sta facendo disinformazione e allarmismo ingiustificato.

  • # 30
    floc
     scrive: 

    usare un filesystem che non si conosce (e per giunta nuovissimo!) e lamentarsi della perdita dei dati e’ come usare un coltello senza sapere dove sta il manico e lamentarsi per essersi tagiliati.

    un filesystem e’ x forza di cose un compromesso tra velocita’ e affidabilita’, sta all’utente scegliere cosa usare. Se poi usa ubuntu cliccando avanti avanti avanti francamente se le va a cercare

    E’ inutile citare slogan sbandierati tipo “defective by design”, ogni fs ha il suo utilizzo, per questo non esiste risposta alla domanda “qual e’ il fs migliore?”, ma solo a “qual e’ il miglior fs per fare QUESTO?” E su una macchina senza ups a monte usare un fs con delayed allocation e’ semplicemente incosciente, altrove puo’ essere vantaggioso

    basta informarsi e uscire dall’idea della “pappa pronta” e “avanti avanti avanti” che su sistemi operativi non giocattolo NON deve esistere secondo me.

  • # 31
    Cesare Di Mauro
     scrive: 

    @Ciano: infatti son problemi dei creatori dei filesystem. :D
    Secca però notare come cerchino di scaricare le colpe sulle spalle dei programmatori delle applicazioni.
    A ognuno i propri bug! :D :D :D

    @floc: non sono assolutamente d’accordo. Le API esistono affinché le applicazioni sappiano come comunicare correttamente le loro esigenze al s.o., e quindi ci si aspetta che funzionino allo stesso modo a prescindere dal fatto che oggi usi JFS o EXT4 o qualunque altro filesystem.

    Un’applicazione è e dev’essere giustamente “agnostica” dal punto di vista del filesystem utilizzato. Non è di loro competenza interfacciarsi direttamente con essi, e infatti le API offrono il livello di astrazione necessario.

    Quindi l’utente è libero di scegliere il filesystem che vuole, ma questi dovrebbero garantire la medesima aderenza alle API, perché l’interfaccia è e deve rimanere omogenea.

    La definizione di s.o. “giocattolo” non la conoscevo. Immagino sia stata coniata da qualche fanatico che non aveva niente di meglio da fare che gettare un po’ di fango sui “soliti noti” giusto per spostare l’attenzione dal contesto troppo scomodo.

  • # 32
    Pizzorante
     scrive: 

    Sono d’accordo con l’ultimo commento di Floc. Al tempo di Windows 2000 ho dovuto inserire nel programma una routine a basso livello di flush forzato sul disco dove salvavo gli archivi alla fine delle operazioni di scrittura ed è stata una benedizione, funziona ancora oggi anche con le “chiavette” e non si è mai perso un bit. La pappa pronta se c’è va bene ma non aiuta a ragionare, purtroppo!

  • # 33
    Cesare Di Mauro
     scrive: 

    @Francesco: mi sono accorto del tuo messaggio soltanto adesso, e ti rispondo.

    Evidentemente non hai compreso bene il problema che ha EXT4 e il ruolo e le responsabilità che hanno un’applicazione, un filesystem e un kernel.

    E’ chiaro che un’applicazione che ha l’esigenza di forzare la scrittura dei dati chiama la fsync, ed è a posto. Altrimenti i dati scritti passeranno, o tramite la fflush o alla fclose, ai buffer del kernel in attesa di venire scritti prima o poi su disco.

    Fin qui mi sembra siamo tutti allineati (e lo spero bene, perché siamo alle basi).

    Ma NON è questa la fonte dei problemi. Il problema è che le politiche allegre scelte da chi ha implementato questi filesystem mettono a rischio la consistenza e l’integrità dei dati.

    Quando io come applicazione ho chiuso il file, il mio lavoro è finito. Il file ha una sua ben precisa dimensione e contenuto. D’altra parte è esattamente quello che mi aspetto. Non si scappa.

    A questo punto mi devi spiegare per quale motivo il file dovrebbe risultare corrotto. Dimmelo tu. Io non ho spento la macchina di botto: è ancora accesa e perfettamente funzionante.

    Se nel file ho scritto “Pippo” perché il filesystem mi ha distrutto questa informazione?

    Ripeto: il file l’ho già chiuso e qualunque entità lo può utilizzare. Lo posso anche cancellare, volendo, ma il punto è che se faccio delle normalissime operazioni, quali un banale rename (vedi gli esempi), mi aspetto di trovare sempre e comunque “Pippo” scritto li dentro. Perché si tratta di un’operazione NON DISTRUTTIVA dell’informazione. E’ un rename, non una truncate!

    Da qui il mio disappunto come programmatore. Tra l’altro ho fornito anche una possibile soluzione al problema che potrebbe conciliare le esigenze prestazionali con l’assoluta necessità di mantenere i dati da parte di un filesystem (d’altra parte il suo compito è questo, no? Non di giocare coi dati che gli mettiamo in mano).

    E per favore: evitiamo di tirare in ballo titoli nobiliari. I programmatori di filesystem o kernel non hanno nulla di speciale rispetto ai programmatori delle applicazioni che faranno uso dei loro filesystem: semplicemente hanno un ruolo di diverso.
    Ma nulla toglie al prestigio di entrambe le figure, perché ognuno in questo mondo fa la sua parte: di un s.o. col solo filesystem e kernel non te ne fai nulla, e viceversa un’applicazione senza filesystem e kernel non va da nessuna parte.

    Atteniamoci ai FATTI e lasciamo perdere le cariche, che servono soltanto a chi ha bisogno di misurarselo anche dopo aver raggiunto la maggiore età.

    Per il resto, forse non c’hai fatto caso, ma avevo già passato i link allo standard POSIX.

    @Pizzorante: purtroppo mancano informazioni per poter avanzare una qualche ipotesi.

  • # 34
    Marco
     scrive: 

    > che tra l’altro ai tempi aveva già un comodissimo
    > sistema di tipo plug & play per montare e smontare a
    > piacimento nuovi filesystem “a caldo”, senza mai
    > riavviare la macchina

    Il plug & play (autoconfig nella versione Amiga) configurava automaticamente le periferiche al boot, con i filesystem c’entra poco. Poi riavviare una macchina per montare un filesystem mi giunge nuova…

  • # 35
    Cesare Di Mauro
     scrive: 

    Infatti ho scritto “TIPO Plug & Play”. L’autoconfig mi è ben noto, e serve ad altro, come hai giustamente riportato.

    Quanto al riavviare una macchina per montare un filesystem mi riferivo al fatto che a volte capita che con l’installazione di driver di questo tipo sia necessario far ripartire la macchina prima di poter effettivamente utilizzare il nuovo filesystem.
    Con l’Amiga ciò non era necessario, appunto: bastava copiare i file nelle giuste cartelle, fare un doppio click sull’iconcina del nuovo filesystem, ed eri già operativo.

    Spero di essere stato chiaro.

  • # 36
    Marco
     scrive: 

    Allora:

    > sistema di tipo plug & play per montare e smontare

    Lo so che ti riferivi all’autoconfig, ma da questa frase sembra che serva proprio per montare e smontare i filesystem. Non sei stato propriamente chiaro.

    In secondo luogo il caricamento di un driver di per se’ non ha nulla a che fare con il mount di un filesystem e ancora una volta non ha nulla a che vedere con il plug&play.

    Era giusto per precisare.

  • # 37
    Cesare Di Mauro
     scrive: 

    Permettimi: se non hai installato correttamente tutti i file necessari, non puoi certo montare il filesystem che ne ha bisogno. E se per usarli è necessario prima riavviare la macchina, mi sembra di non aver detto un’eresia prima.

    Per il resto scusami per la poca chiarezza.

  • # 38
    Alberto
     scrive: 

    Beh.. riavviare una macchina per poter utilizzare un nuovo FS lo trovo ridicolo anche io soprattutto nel 2009… :) I moduli del kernel esistono da tempo.. magari qualcuno sarebbe anche ora che ci pensasse. Risulta ovvio come dice Cesare che se manca qualche pezzo il FS non lo puoi usare.. una kldload ZFS non carica solo il modulo in oggetto.. ma anche aio.ko e solaris.ko per dipendenza.
    Per tornare in topic e rispondere anche a Francesco.

    Io programmatore non devo essere obbligato a conoscere gli internal di un FS (soprattutto in un caso come questo). Il FS puo’ anche decidere di fare una delayed write o una delayed allocation MA se io ho chiuso il File Descriptor e poi effettuo una rename, i dati debbono essere scritti coerenti. Che sia il FS a segnarsi che ho fatto la rename prima che lui abbia scritto i dati e quindi lo faccia in modo coerente… oppure che venga implementato un sistema che all’esecuzione di alcune chiamate API (rename nel caso) si preoccupi di fare il flush dei dati e le allocazioni necessarie.
    Qui’ non si tratta di assicurare che il flush venga fatto, ma il dover forzare la scrittura dei buffer perche’ un operazione non distruttiva potrebbe portare alla perdita dei dati.. e questo NON ha senso.. a prescindere dagli internals o dal design del FS.
    Anche su ZFS non ho mai riscontrato il problema, eppure pare che ci sia la possibilita’.

  • # 39
    Cesare Di Mauro
     scrive: 

    Alberto, che dire: d’accordissimo su tutta la linea.

    E da programmatori non dovrebbe che essere questa la linea di pensiero. Mi spiace che altri non condividano.

  • # 40
    sirus
     scrive: 

    @ Cesare Di Mauro
    Forse non ho letto con attenzione le specifiche di close() ed fclose() ma non mi pare che close() il flush dei buffer contrariamente a quanto avviene con fclose().
    Sono più propenso a pensare che fclose() si traduca in una sequenza fsync() close() piuttosto che close() si traduca in una sequenza fflush() fclose().

  • # 41
    sirus
     scrive: 

    Nota a margine, se l’implementazione di fclose() fosse veramente una sequenza fsync() close() si potrebbe spiegare perché nell’esempio riportato sul bug tracker lo sviluppatore abbia esplicitamente riportato close() e non fclose().

  • # 42
    Alberto
     scrive: 

    @cesare… sarebbe come se in un DB io faccio una Insert e poi un update e il db si perde per strada l’update perche’ in realta’ la insert non era ancora stata scritta… Vedi quanta gente avrebbe appeso il caro Larry (per citarne uno solo) per i maroni.. :D
    L’integrita’ viene garantita…. mi stupisce che nel design di un FS questi aspetti non vengano tenuti in considerazione.. tanto piu’ che non si parla di tecnologie aliene o implementazioni sconosciute.. sono 30 e passa anni che si fanno FS.

  • # 43
    Cesare Di Mauro
     scrive: 

    @sirus, la fclose, come dicevo prima, serve soltanto a svuotare il suo buffer interno e a chiamare poi la close.

    Ne ho recuperato un’implementazione qui di cui riporto il codice di seguito:

    /* FIXME: Last file not removed from list. */
    18 int fclose( struct _PDCLIB_file_t * stream )
    19 {
    20 struct _PDCLIB_file_t * current = _PDCLIB_filelist;
    21 struct _PDCLIB_file_t * previous = NULL;
    22 /* Checking that the FILE handle is actually one we had opened before. */
    23 while ( current != NULL )
    24 {
    25 if ( stream == current )
    26 {
    27 if ( stream->status & _PDCLIB_WROTELAST ) fflush( stream );
    28 if ( stream->status & _PDCLIB_LIBBUFFER ) free( stream->buffer );
    29 _PDCLIB_close( stream->handle );
    30 if ( previous != NULL )
    31 {
    32 previous->next = current->next;
    33 }
    34 else
    35 {
    36 _PDCLIB_filelist = current->next;
    37 }
    38 return 0;
    39 }
    40 previous = current;
    41 current = current->next;
    42 }
    43 return -1;
    44 }

    E’ da decenni che si implementa in questo modo. Poco meno di una ventina d’anni fa implementai anch’io queste utili primitive per l’I/O bufferizzato su AmigaOS, perché la libreria di sistema (dos.library) non le forniva. Anche se ai tempi non usavo il C, ma quasi esclusivamente l’assembly.

    Ripeto: è “ordinaria amministrazione”. E come vedi l’applicazione non ha potere di far nulla, se non per i propri buffer. A quelli del kernel deve pensarci il kernel in “combutta” col filesystem. E prendersi carico delle proprie responsabilità.

    @Alberto: esempio azzeccatissimo. :D

    Per me si tratta di scarsa professionalità e conoscenza dei ruoli di applicazione, filesystem e s.o..

  • # 44
    syd
     scrive: 

    Grazie per l’ottimo articolo. Per me scegliere il filesystem è un grande dilemma…cosa è meglio, cosa è peggio? Per esempio, si diceva di non usare Reiser perché il suo creatore è in galera, però pare che lo sviluppo continui. Riguardo EXT…siccome EXT4 sarà offerto come opzione nella release di Ubuntu che sta uscendo adesso (9.04) concludo che forse è meglio restare sull’EXT3…Sto semplificando troppo? Suggerisci un sito o un libro per orientarsi in questo campo?

  • # 45
    Cesare Di Mauro
     scrive: 

    Dipende da quello che ci fai. Per un uso “desktop” io non ho particolari pretese: l’importante è che sia journaled, che non mi perda i dati (questa per me è condizione assolutamente necessaria) e che offra delle buone prestazioni.

    Non ho libri da consigliarti, eccetto uno se hai intenzione di capire dall’A alla Z come si progetta un filesystem.

    Grazie per i complimenti. :)

  • # 46
    Folgore101
     scrive: 

    @Cesare Di Mauro
    Complimenti per l’articolo, ma potresti essere un pò più esplicito riguardo il tuo post n.45? Un povero utente “desktop” che non mangia FS a colazione e che usa il PC per fare qualche documento con OO, masterizzare, navigare in internet e provare a installare programmi per “prenderci la mano” su cosa si drovebbe orientare secondo te, visto che condivido a pieno le tue necessità espresse nel post n.45?

  • # 47
    Cesare Di Mauro
     scrive: 

    Io prenderei un qualunque filesystem che risponda ai requisiti.

    Personalmente mi sono trovato benissimo con ext3, quando ho usato Linux. Ho sentito parlare bene di jfs, ma non l’ho mai provato, per cui mi astengo dal giudizio.

    Su Windows mi trovo bene con NTFS (anche perché non c’è scelta :D).

  • # 48
    The3D
     scrive: 

    Posix o non posix, c’è poco da fare: se si perdono dei dati in seguito ad operazioni non distruttive, indipendentemente dalla loro sequenza (o anche in modo dipendente, visto che qualcuno si dovrà anche occupare di mantenere la consistenza no? parlo ovviamente della fase successiva al rilascio delle risorse da parte dell’applicazione) c’è qualcosa che non va. Se poi è addirittura lo standard a prevedere (o più correttamente, a non chiarire esplicitamente) situazioni del genere, a parer mio è una mancanza (anche grave) dello standard.

  • # 49
    ext4 considerazioni. « Tecnologia e non solo
     scrive: 

    […] C’è da fidarsi di un filesystem che perde i nostri dati? è un ottimo approfondimento che vi invito a leggere. […]

  • # 50
    Marco
     scrive: 

    Sono d’accordo, per un uso desktop ext3 va piu’ che bene, o cmq quello di default della distribuzione.

    La scelta di filesystem diversi va fatta consapevolmente laddove vi sono necessita’ particolari di prestazioni, capacita’, ecc.: spesso poi va fatto anche un tuning ad hoc (io cmq da anni uso sia jfs che xfs senza particolari problemi).

    C’e’ da dire anche che ext4 e’ considerato da molti un filesystem di transizione verso btrfs (ma con questo nessuna giustificazione per i suoi “difetti”), che portera ad un’allineamento delle features con il tanto decantato zfs. Per la cronaca btrfs e’ gia’ stato incluso nella main line del kernel e marcato come unstable, e si presume che manchi circa un anno al rilascio di una versione stabile (dati da prendere con le pinze!).

  • # 51
    Folgore101
     scrive: 

    Grazie a Cesare Di Mauro e Marco per la risposta.

  • # 52
    Francesco
     scrive: 

    [QUOTE]
    Quando io come applicazione ho chiuso il file, il mio lavoro è finito. Il file ha una sua ben precisa dimensione e contenuto. D’altra parte è esattamente quello che mi aspetto. Non si scappa.
    A questo punto mi devi spiegare per quale motivo il file dovrebbe risultare corrotto. Dimmelo tu. Io non ho spento la macchina di botto: è ancora accesa e perfettamente funzionante.
    [/QUOTE]
    Invece non è così. Tutta questa discussione (e la notizia) nasce perché hai capito male il problema. L’articolo è errato, il problema NON si verifica senza blackout, il file risulta corrotto SE E SOLO SE spegni la macchina di botto o se il sistema va in crash. “Ext4 behaves precisely as demanded by the POSIX standard for file operations”. Se fai una rename di un file in cui hai appena scritto Pippo, non c’è scritto Pippo su disco finché la scrittura non avviene realmente, il che non accade se il sistema va in crash o viene spento bruscamente. Se tu vai a leggere il file dopo la rename il contenuto lo trovi perché il kernel te lo restituisce dai suoi buffer. Deve solo essere scritto su disco. Evidentemente non hai capito che la perdita di dati deriva proprio da questo, non durante un normale utilizzo del filesystem. Secondo te un problema del genere sarebbe saltato fuori solo adesso se fosse stato veramente così? I dati si perdono solo in caso di crash, e questo perché i dati vengono scritti più tardi per ottimizzare le prestazioni, come succede in tutti i filesystem. Solo che l’ext3 li scrive al massimo dopo 5 secondi. Così, dato il predominio dell’ext3 nell’uso dei filesystem per Linux, gli sviluppatori di applicazioni hanno dato per scontato questo comportamento per tutti i filesystem, sbagliando.

    Fonti:
    http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds–/news/112892
    http://www.h-online.com/open/Possible-data-loss-in-Ext4–/news/112821
    citate da Slashdot nelle due rispettive notizie dedicate:
    http://linux.slashdot.org/article.pl?sid=09/03/11/2031231&tid=198
    http://linux.slashdot.org/article.pl?sid=09/03/19/1730247

    Quindi andate a leggervi questi articoli, perché non avete capito il problema.

    Comunque gli sviluppatori di un kernel o di un filesystem non nascono con sangue nobile, e per arrivare ad un certo livello ci vogliono conoscenze e impegno sopra la norma ed è quindi normale dubitare di quanti gli diano contro trovandosi sotto di essi in entrambi questi punti, senza neanche chiedersi se sia davvero possibile che tali sviluppatori permettano un problema del genere e approfondire.

  • # 53
    goldorak
     scrive: 

    Quoto Franceso, ma dico anche una parte di responsabilita’ ce l’hanno gli sviluppatori del fs ext 4. Non e’ concepibile che i dati nei buffer del kernel stiano li’ per decine di secondi (anche interi minuti !!!) prima di essere scritti sul disco.
    Non quando un tale fs verra’ usato su sistemi desktop in cui occorre tenere presente eventuali black out etc…
    In sistemi server dove ci sono ups, schede raid con batterie tampone etc.. questo problema di delayed allocation viene mitigato. Ma non si puo’ pensare di usare pari pari un tale fs sul desktop degli utenti normali perche’ si va incontro ai problemi descritti sopra.
    Questa mania di voler adoperare soluzioni che vanno bene in ambito server su desktop e’ una malattia che linux deve correggere. Perche’ cosi’ com’e ext4 e’ totalmente inutile in ambito desktop. Non si deve mai e poi mai sacrificare la consistenza del fs sull’altare delle pure prestazioni.

  • # 54
    floc
     scrive: 

    @cesare di mauro:

    l’articolo sostiene (e a ragione) che alcuni fs sono piu’ inclini a perdere dati in caso di imprevisti. Vero, ogni fs ha i suoi pro e i suoi contro per velocita’ e affidabilita’, sta all’utente scegliere di quale servirsi a seconda delle situazioni. punto. Non capisco cosa c’entri il discorso sui programmi ne’ sulle api, se tutti i fs funzionassero allo stesso modo sarebbero uguali, non avrebbe senso averne di differenti, non trovi? Il fs perfetto non esiste (ancora), viviamo di compromessi, all’utente informato scegliere quali, se poi non ci si informa…

  • # 55
    floc
     scrive: 

    @goldrak: non si deve mai e poi mai…. chi lo dice? tu? se uso sistemi dove mi interessano SOLO le prestazioni e sono SICURO che non ho cali di tensione non vedo perche’ privarmi della possibilita’ di usare ext4
    che poi ci sia chi lo mette su ubuntu e ci resta male… problemi suoi :) ci sono un mucchio di alternative

  • # 56
    goldorak
     scrive: 

    @floc : tu a casa disponi di un gruppo elettrogeno autonomo che alimenta il tuo pc ?
    Vedi gran sapientone, le scelte che sono state fatte per ext 4 hanno senso in ambito server.
    L’errore commesso e’ stato nel far credere a tutti che un tale fs possa andare bene anche in ambito desktop.
    Ma ce lo immaginiamo si o no il casino che verrebbe fuori contro la MS se ad ogni imrpovviso blackout si dovesse reinstallare xp perche’ il sistema non e’ in grado di garantire la consistenza e l’integrita’ dei dati ?
    Va va, un fs che mette le prestazioni davanti alla consistenza ed integrita’ dei dati in ambito desktop e’ da buttare nel cesso senza se e senza ma.

  • # 57
    Nicola
     scrive: 

    io appoggio la tesi di cesare

    non è questione di “perdita di dati” per cause accidentali, ma di “corruzione di dati” per cause implementative.

    anche se i dati non vengono scritti sul disco REALMENTE dopo la close, il filesystem deve tenerlo in considerazione.

  • # 58
    j
     scrive: 

    “Quindi andate a leggervi questi articoli, perché non avete capito il problema.”

    si può leggere quanti articoli si vuole ( nonchè la discussione precedentemente linkata da sirus sul blog dello stesso Theodore Ts’o – discussione che raccomando caldamente, perchè illuminante)
    ma il problema resta – e se non vedo male si parla di zero-lenghting di file aperti, anche in caso di crash del processo che aveva aperto il file – e non solo in caso di mancato shutdown o di blackout (o altro evento provocante spegnimento improvviso della macchina, che non dipenda dalla volontà o esperienza dell’ utente – e per questo non evitabile)
    quindi non si tratterebbe della sola “perdita delle ultime modifiche” ad un file, che un processo “crede” di aver effettuato ma che in realtà non sono state effettuate perchè non è stata chiamata la fsync(), effetto della cui responsabilità a livello programmatico si potrebbe discutere per ore (magari senza nemmeno venire a un accordo) ma che si può ritenere “accettabile” nell’ ottica del comportamento di un sistema e uno standard che, oggettivamente, non danno garanzie di robustezza dei dati
    qui si ha a che vedere con qualcosa che dovrebbe far inorridire e preoccupare chiunque…

  • # 59
    kentaky
     scrive: 

    alla faccia di chi sbandierava la superiorità di EXT4 rispetto a NTFS…
    EXT4 è solo superiore nel perdere i tuoi dati! :-)

  • # 60
    pabloski
     scrive: 

    beh posso dire che cesare mi ha salvato la cotica….avevo deciso di passare a ext4 ma me ne terrò alla larga ancora per qualche annetto visto come stanno le cose

    comunque il problema non riguarderebbe il fs qualora la perdita di dati avvenisse a causa di blackout o altre cause fisiche

    ma in questo caso si sta invece parlando di un chiaro flaw implementativo….guardate che è successo a questi https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781

    in pratica kde crasha e io perdo i dati? un programma può crashare e i dati inviati ai buffer del sistema operativo DEVONO essere scritti sul disco…quindi di che si lagna quel tipo che se la piglia con le applicazioni?

    in sostanza il punto è che quando ho aperto, scritto e chiuso il file il mio compito è finito, la palla passa all’OS

    non si può non essere d’accordo su questo

  • # 61
    Cesare Di Mauro
     scrive: 

    Dagli ultimi messaggi non posso che apprezzare il fatto che il mio messaggio è stato recepito e che è servito a mettere in guardia gli utenti, ma soprattutto al sicuro i loro dati.

    Come articolista mi ritengo pienamente soddisfatto e ringrazio tutti per i complimenti.

    Davvero grazie a tutti.

  • # 62
    Ciano
     scrive: 

    @Cesare Di Mauro
    Grazie a te per l’articolo :)

  • # 63
    sirus
     scrive: 

    @ Cesare Di Mauro
    Il codice che hai postato non prova che close() effettui il flush dei buffer e neppure lo standard POSIX lo prevede. Considerando che gli esempi postati sul bug tracker utilizzano close() e non fclose() può essere che siano esempi validi.

  • # 64
    Cesare Di Mauro
     scrive: 

    @sirus. fclose si comporta esattamente come close (a parte il flush del suo piccolo buffer interno).

    I problemi sono altri: se leggi i precedenti messaggi degli altri utenti che sono intervenuti, trovi la chiave di tutto (che non sono nemmeno i soli 5 secondi di attesa di EXT3 rispetto ai 30 o più di EXT4 per il sync “automatico”).

  • # 65
    Francesco
     scrive: 

    Cioè, anche dal link che ha inviato pablosky ( https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 ) si legge chiaramente che c’è stata una power loss e una system crash. Non si parla di una crash di un’applicazione ma dell’intero sistema. E finora non ho trovato fonti che affermino il contrario quindi non capisco da dove tiriate fuori queste affermazioni. Per favore, illuminatemi.

  • # 66
    Cesare Di Mauro
     scrive: 

    Non ti fermare al primo commento: leggi anche quelli seguenti.

  • # 67
    diggita.it
     scrive: 

    C’è da fidarsi di un filesystem che perde i nostri dati?…

    I filesystem moderni fanno uso dell’allocazione ritardata e, quindi, sono soggetti a possibili perdite di dati. Da una rapida ricerca sembra, invece, che siano soltanto cinque: HFS+, XFS, Reiser4, ZFS ed ext4….

  • # 68
    floc
     scrive: 

    @goldrak: si’, io ho gruppi di continuita’ ovunque, anche a casa.

    detto questo, ripeto che ognuno puo’ scegliere cio’ che preferisce e visto che ci sono parecchie alternative, lamentarsi perche’ e’ stata fatta una scelta sbagliata non ha senso. Serve scegliere piu’ accuratamente, non lamentarsi perche’ esistono alcuni fs che per design sono meno sicuri di altri in caso di crash.
    se poi vuoi buttarla sulla rissa verbale accomodati pure ma non ho intenzione di seguirti, mi sembra che il concetto che ho espresso sia sufficientemente chiaro: bisogna conoscere cio’ che si usa, pregi e difetti.

  • # 69
    Cesare Di Mauro
     scrive: 

    Mi spiace, ma non concordo. Tu stesso hai detto che è stata fatta una scelta sbagliata. Se è sbagliata, la si corregge allora, ammettendo il proprio errore.

    Quanto al “bisogna conoscere ciò che si usa” mi trovi assolutamente d’accordo, ma questo significa conoscere anche il significato di applicazione, kernel e filesystem e i rispettivi ruoli.

    Se io scrivo un’applicazione rispettando le specifiche (delle API) e chiudo un file, non mi posso sentire trattato come un idiota che non sa programmare perché avrei dovuto usare la fsync, e se decido di farlo poi non è ancora contento perché genero tanti piccoli file.

    Cioé, ma ci rendiamo conto che qui siamo arrivati al paradosso che un programmatore si deve sentire in colpa per avere generato un po’ di file che consumano pochi byte. Ma saranno mica fattacci miei?

    Tu sviluppatore di filesystem, invece, fai il TUO dovere, anziché scaricare le TUE colpe sugli altri.

    Perché se io il file l’ho chiuso (anche senza fsync) e te l’ho consegnato, adesso non ho più alcun potere su di esso (e mi sembra ovvio). Te l’ho affidato, ma per colpa delle tue scelte me l’hai corrotto.

    Non ci sono scuse da bambini delle elementari che sono stati sorpresi con le mani nella Nutella e nonostante l’evidenza tentano ugualmente di dar colpa a qualcun altro.

  • # 70
    Daniele
     scrive: 

    Per quanto mi riguarda leggendo i commenti sparsi per il web sono d’accordo con Francesco.

    L’articolo è allarmistico nel senso che EXT4 NON sarebbe da usare se non per testing e da questo punto di vista Cesare ha ben fatto!

    Poi puoi usare tutti i filesystem che vuoi, ma se poi il 98% degli utenti tiene la cache disco attiva senza UPS vabbè… auguri!

  • # 71
    Cesare Di Mauro
     scrive: 

    Sì, ma altri filesystem degni di questo nome (perché ottemperano al mandato che gli è stato dato) in questi casi non ti rasano a zero i file. :D

  • # 72
    floc
     scrive: 

    ancora non ci capiamo:

    io utente so che il filesystem XY per progettazione usa determinate procedure e per questo ha vantaggi e svantaggi: decido che mi fa schifo e non sono d’accordo e non si lavora cosi’ e solo un pazzo lo userebbe? non lo uso :)

    Io pazzo che invece voglio sacrificare i dettami della buona programmazione sull’altare della velocita’, avro il mio diritto ad avere un fs che rispecchi i MIEI requisiti o no?

    poi chiaro che se lo sviluppatore del fs se la prende con il programmatore il cretino e’ lui, su questo ti do perfettamente ragione, ma non capisco perche’ sparare a zero su prodotti che evidentemente hanno priorita’ diverse. Se io so x certo che i prog che uso su qual fs mi enerano sempre almeno tot byte e quindi non ho il problema del tuo esempio? a me puo’ andare benissimo, conosco bene il fs e lo uso

    abbiamo una valanga di scelte, non vedo perche’ privarsi a priori di alcune di queste solo perche’ di nicchia

  • # 73
    floc
     scrive: 

    ERRATA: “Se io so x certo che i prog che uso su quell’fs mi generano…”

    scritto troppo in fretta sorry :)

  • # 74
    Cesare Di Mauro
     scrive: 

    Figurati, sai quanti ne commetto io di errori. :D

    Sono perfettamente in linea con quello che hai detto, anche perché a mio avviso sintetizza in maniera chiara e semplice la situazione.

    Sai, allora, qual è il problema? E’ che quei folli di Ubuntu hanno deciso di mettere un filesystem così instabile, e disegnato più per dei server, su… un s.o. mainstream, indirizzato alla massa.

    Puoi immaginare le conseguenze di ciò. La massa non è come me e te, che ci documentiamo e certi strumenti sappiamo che dobbiamo manipolarli coi guanti bianchi, e in un certo modo.

    E il bello è che ormai da tempo continuano con questa politica disgraziata da tempo.

    Le ultime tre stupidaggini che hanno commesso in ordine di tempo:
    – integrare KDE 4.1, che è ancora immaturo e bacato, non lasciando la possibilità di poter usare anche la stabile e ben collaudata 3.5 (ovviamente la puoi mettere, ma soltanto installandola tu stesso a parte);
    – mettere FireFox 3.0 beta come browser principale;
    – mettere Python 2.5 con gli header del 2.4 (e questo ha generato problemi a installare pacchetti come ice di zeroc).

    Ripeto: stiamo parlando di un s.o. mainstream che dovrebbe far concorrenza a Windows e si comporta molto, ma molto peggio!

    Giudica tu se è una politica condivisibile, la loro.

  • # 75
    massimo m.
     scrive: 

    il filesystem di per se’ NON ha politiche delayed.
    e’ il so che lo fa. su qualsiasi fs si puo’ fare, volendo.
    anche la fat, se non ricordo male, aveva un sistema simile, attivabile su richiesta.
    semplicemente il kernel tiene in memoria in cambiamenti, poi decide quando scrivere su disco. ma non e’ il fs che lo fa, ma il kernel.

    semplicemente il kernel decide quando leggere/scrivere in memoria o su disco (volendo si potrebbe anche con la fat), e un kernel decente DEVE dare la possibilita’ tramite proc tuning, di decidere dopo quanti secondi scrivere su disco (ma di default dovrebbe essere zero, almeno imho).
    cosi’ uno puo’ decidere: se si tratta di server mission critical in cui un dato DEVE essere subito scritto su hd, si usa zero secondi, se si tratta di office automation, giochi o comunque dove ripristinare i dati da un backup non sia un dramma, allora si possono usare tempi molto lunghi.

  • # 76
    Daniele
     scrive: 

    Per citare massimo m. l’opzione “sync” di mount serve proprio per questo? O mi sbaglio?

  • # 77
    Cesare Di Mauro
     scrive: 

    Attenzione. Che sia il kernel a decidere quando effettuare il sync dei suoi buffer è cosa nota, ed è stato anche chiarito.

    Ma le politiche di allocazione non le decide lui. Ogni filesystem ha la sua particolare struttura ed è il codice specifico del filesystem che si occupa di gestirla.

    Per fare un esempio: FFS (o amyfs), che è il filesystem dei vecchi Amiga, è supportato da Linux, ma ha una struttura completamente diversa da EXT*, Raiser*, XFS, JFS, ecc. ecc.

    Poi per il resto concordo con massimo m., ma ho ritenuto doveroso precisare questo importante dettaglio.

    Questo perché, come ripeto da un po’, applicazioni, kernel e filesystem hanno dei ruoli ben definiti.

    @Daniele. L’opzione sync serve a effettuare il mount del filesystem in modo da eseguire sempre la sincronizzazione dei dati e, quindi, riversarli immediatamente nel disco. Equivale a invocare sempre la fsync per ogni operazione, dunque letteralmente può uccidere le prestazioni del sistema.

  • # 78
    Ciano
     scrive: 

    (74) di Cesare Di Mauro – Postato Venerdì 3 Aprile 2009 alle ore 16:20

    […]
    Sai, allora, qual è il problema? E’ che quei folli di Ubuntu hanno deciso di mettere un filesystem così instabile, e disegnato più per dei server, su… un s.o. mainstream, indirizzato alla massa.
    […]

    Secondo me, per come è progettato ora non è utilizzabile soprattutto su dei sistemi server, per il semplice motivo che o “uccidi le prestazioni” disattivando le scritture deferred dal mount oppure devi essere certo che ogni servizio e processo che fai girare utilizzi la fsync() prima di ogni chiusura, altrimenti come puoi fidarti a lanciare uno script che per esempio sposta dei file se poi non sai se ci sono dei dati nel buffer che non sono stati scritti e verranno persi.

    PS: con “uccidi le prestazioni” non intendevo che per forza il sistema diventa una lumaca, è tutto da valutare.

  • # 79
    Cesare Di Mauro
     scrive: 

    La mia opinione è diametralmente opposta e ti spiego il perché.

    Sui server un filesystem del genere può andare bene perché funzionano 24h/24 e sono attaccati a gruppi di continuità che non sono paragonabili ai nostri “caserecci”.

    Sono sistemi fatti per lavorare sempre. Ed ecco che un file system che allunga fino a 30 secondi o anche più le scritture risulta decisamente più performante e utile, perché il sistema risulta anche ottimizzato (si eseguono batch di scritture sequenziali, anziché n singole richieste sparpagliate). Poi ci possono essere server per cui è necessario che i dati siano scritti subito, ma in generale la situazione è questa.

    In ambito desktop, invece, c’è il classico utente che può non avere il gruppo di continuità, e magari utilizza una distro instabile che può portare a crash del sistema.

    In questo contesto un filesystem che esegue il batching delle richieste dopo 30 secondi o addirittura un minuto è un vero suicidio, perché si potrebbero facilmente perdere i dati, com’è puntualmente avvenuto a tantissima gente (ci sono commenti ovunque: la “febbre” dell’EXT4 bacato impazza sul web).

    Se, come diceva anche massimo m., puoi farti un backup (o come dicevo prima, hai un gruppo di continuità) o hai un sistema stabile, o come diceva floc sono uno che è ben consapevole e tiene conto di tutto ciò, nulla ti vieta di usarlo così com’è.

    Di una cosa però sono certo: non si può mettere in mano EXT4 all’utente qualunque, che è il target primario di Ubuntu. Nella maniera più assoluta.

  • # 80
    floc
     scrive: 

    “Sai, allora, qual è il problema? E’ che quei folli di Ubuntu hanno deciso di mettere un filesystem così instabile, e disegnato più per dei server, su… un s.o. mainstream, indirizzato alla massa.”

    questo e’ un altro discorso e hai non ragione, di piu’! :)
    ubuntu ha il grande merito di essere apprezzabile subito da tutti anche dai meno esperti, ma ha seri problemi sotto altri aspetti. Io consiglio sempre di assaggiare ubuntu, poi andare su qualcosa di piu’ “serio” per imparare davvero come gira tutto, e poi, al limite, tornare su ubuntu con cognizione di causa e sistemarla a dovere

  • # 81
    Cesare Di Mauro
     scrive: 

    Il fatto è che con queste mosse troppo azzardate rischia di perdere credibilità e appeal per chi vuole sceglierla per un utilizzo tipicamente “desktop”.

    Fra i miei colleghi tanti l’hanno già abbandonata non perché adesso sono smanettoni (lo erano già prima), ma perché cercavano una distro comoda da usare per lavorare, senza troppi pensieri.

    Perché è innegabile che un s.o. già “pronto all’uso”, che non ti fa perdere tempo in configurazione e aggiornamento, è molto appetibile per chi pensa che il tempo sia denaro e non ne vuole perdere.

    Il tutto, come al solito, IMHO.

  • # 82
    floc
     scrive: 

    vero, forse la verita’ purtroppo e’ che linux non e’ davvero pronto ad entrare nel mercato desktop “per tutti”, e queste scelte azzardate di ubuntu nel tentativo di mediare features/facilita’ di utilizzo ne siano una testimonianza

  • # 83
    massimo m.
     scrive: 

    quoto floc, linux al momento non e’ assolutamente pronto per essere il so per tutti.
    o meglio, io penso che e’ perfetto se hai un amico che te la puo’ installare e configurare, e poi tu devi solo lavorare e basta. in quel caso e’ ottimo perche’ non si sconfigura mai (distro serie, intendo, io uso solo slack). in azienda sarebbe perfetto. un sitemista ti installa il so, te lo gestisce e tu non hai la possibilita’ di massacrarlo.
    ma di sicuro non per gente che devono installare loro driver e via dicendo.

    ubuntu puo’ essere un’arma a doppio taglio: da una parte avvicina gli utenti a linux, dall’altra pero’ quando uno si trova davanti ai gravi limiti di ubuntu si comincia a chiedere “ma e’ questo linux? non dovrebbe essere stabilissimo, performante, affidabile? io mi tengo windows!”.
    vi posso assicurare che e’ un discorso che ho gia’ sentito (e infatti dopo aver fatto assaggiare linux con ubuntu live, installo slack, e a quel punto si dimostrano piu’ che soddisfatti).

  • # 84
    Ciano
     scrive: 

    (79) di Cesare Di Mauro – Postato Sabato 4 Aprile 2009 alle ore 06:56

    La mia opinione è diametralmente opposta e ti spiego il perché.

    Sui server un filesystem del genere può andare bene perché funzionano 24h/24 e sono attaccati a gruppi di continuità che non sono paragonabili ai nostri “caserecci”.

    Sono sistemi fatti per lavorare sempre. Ed ecco che un file system che allunga fino a 30 secondi o anche più le scritture risulta decisamente più performante e utile, perché il sistema risulta anche ottimizzato (si eseguono batch di scritture sequenziali, anziché n singole richieste sparpagliate). Poi ci possono essere server per cui è necessario che i dati siano scritti subito, ma in generale la situazione è questa.
    —————————————–

    Forse non mi sono fatto capire (succede spesso).
    Non sono contrario all’utilizzo di buffer (anche molto grandi) sia su server (che in genere hanno UPS e RAM ECC) che client (dove di solito non sono critici), sono contrario al modo che ha EXT4 assieme al kernel di gestire la coerenza.
    Se voglio migliorare le prestazioni e decido di implementare un buffer in lettura/scrittura come minimo mi devo preoccupare di gestire la coerenza dei dati tra buffer e disco.
    Se dovessi farlo io, a istinto farei tutte le modifiche nel buffer in questo modo posso gestire le scritture quando voglio, poi implementerei delle specie di tag o flag per sapere quali blocchi sono stati scritti su disco o modificati e non sincronizzati.
    Se eseguo alcuni comandi di scrittura sul buffer ed altri comandi direttamente su disco è ovvio che prima o poi qualcosa rischio di perderlo per strada.
    Nel caso invece di crash o disalimentazione buffer o non buffer non ci si può fare nulla, salvo affidarsi al journaling.

    PS: Nei messaggi mi riferisco sempre al BUG report su EXT4 e non in generale su Linux o altri FS.
    PPS: Non sono abbastanza informato su come viene gestito il buffer, se dal kernel o dal driver Ext4, perdonate eventuali essori.

  • # 85
    Ciano
     scrive: 

    Bella questa “perdonate eventuali essori.” ovviamente era “errori” :)

  • # 86
    Cesare Di Mauro
     scrive: 

    In tal caso devi scusare anche me, che non ero riuscito a comprendere esattamente cosa intendessi.

    Per rispondere alla tua domanda, i buffer generalmente sono di dominio del kernel, che li utilizza per il caching, appunto.

    E’ molto difficile che un filesystem faccia la stessa cosa, perché i dati sono un concetto più astratto che trascendono dalla particolare implementazione del filesystem.

    Un blocco di dati letto o scritto è sempre lo stesso, a prescindere che tu l’abbia recuperato da un EXT3 o da un JFS.

    Comunque volevo ringraziare tutti quelli che hanno partecipato alla discussione perché, a parte qualche momento di tensione, su un argomento così delicato non ci si è arenati sulle classiche diatribe Questo vs Quello e si sia affrontato esclusivamente sul piano tecnico.

    Quando si disquisice in questo modo abbiamo tutti da guadagnarci, perché, chi più chi meno, portiamo a casa un bagaglio culturale arricchito.

    Grazie veramente a tutti! :)

  • # 87
    BloggUccio » Attenzione ad Ext4
     scrive: 

    […] C’è da fidarsi di un filesystem che perde i nostri dati? […]

  • # 88
    Ha senso un file system case sensitive? - Appunti Digitali
     scrive: 

    […] Nella letteratura informatica quello dei filesystem è un argomento particolarmente caro, ampiamente trattato e sul quale la ricerca non manca; anzi. D’altra parte è anche prevedibile, considerata la loro importanza: è questo “pezzo di codice” a cui affidiamo i nostri dati (a cui ovviamente teniamo). […]

  • # 89
    EXT4: terrosismo mediatico? « Tecnologia e non solo
     scrive: 

    […] 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). […]

  • # 90
    Emanuele Rampichini
     scrive: 

    Posso provare a inserirmi nella discussione con uno spunto? Premetto che non utilizzo ubuntu da un paio di anni (abbandonato principalmente per la troppa complessità del sistema che mi richiedeva abbastanza tempo per essere gestita al meglio) e sono ormai stabile su Arch Linux (molto più semplice e flessibile per le mie esigenze, ovviamente non più facile). Si potrebbe affermare ribaltando il punto di vista che canonical con le sue risorse stia facendo moltissimo. Sta facendo quello che redhat e novell non sono mai riuscite a fare a livello desktop (ovviamente il desktop non è il loro core business ma credo non sia nemmeno quello di canonical che mira più che altro attraverso il desktop a conquistare fette lato server, workstation e nelle pubbliche amministrazioni dove ci sono i ricchi contratti di assistenza). Mi è capitato di vedere utilizzare ubuntu anche a persone che se solo 4 o 5 anni fa avessero sentito la parola linux avrebbero pensato ad un insulto :D . Sono stati fatti accordi con la dell per la preinstallazione nei portatili (ed in questo frangente se qualcuno segue la situazione sa che hanno tenuto la 8.04 solo per passare recentemente alla 9.04).

    Altro discorso naturalmente per quanto riguarda le regressioni. Regressioni ci sono state e sempre ci saranno (chi non ha subito la via crucis dei driver video intel, per non parlare dei driver proprietari ati), ma credo che il loro maggiore eco rispetto al passato sia dato principalmente dal fatto che il bacino di utenza si è allargato molto. Ovviamente questo non giustifica il fatto che tali regressioni si presentino ma è una buona attenuante per una azienda che ricordiamo è microscopica se paragonata anche solo al panorama che ruota intorno a linux.

    Diamo tempo al tempo e vediamo se canonical sarà capace di imparare dai propri errori. Io mi sento di poter scommettere che lo farà.

  • # 91
    Emanuele Rampichini
     scrive: 

    Ho sbagliato articolo. Scusate! :-)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.