Theodore Ts’o ha comunicato alla Linux Kernel Mailing List ( LKML ) la ripresa dei lavori su ext4, il filesystem successore di ext3 di cui Matteo ha già parlato in due diverse occasioni; nella sua mail il noto kernel hacker ha spiegato che i ritardi accumulati nello sviluppo e la mancata integrazione del lavoro svolto all’interno del kernel vanilla sono stati causati dall’eccessivo numero di persone che stanno partecipando allo sviluppo.
Qualcuno si starà chiedendo come sia possibile una cosa simile, vero? Beh, innanzitutto molti di questi sviluppatori sono nuovi, pertanto le loro patch devono essere analizzate minuziosamente prima di essere accettate a monte ( e ciò ruba tempo allo sviluppo vero e proprio ); se a questo si aggiunge che chi dovrebbe rivedere il codice è impegnato anche in altri progetti ( con la conseguenza che il tempo disponibile per lo sviluppo e la revisione del codice di ext4 si riduce ulteriormente ) si comprendono chiaramente i motivi di questo ritardo.
Mistero risolto? Sembra proprio di sì…ora non ci rimane che augurare buon lavoro ai vecchi e nuovi kernel hacker…c’è ancora molto da fare! 
[ via KernelTrap ]
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
carandiru.it
08 mag 2007 - 10:13 - #1Riprende lo sviluppo di EXT4Theodore Ts’o ha comunicato alla Linux Kernel Mailing List ( LKML ) la ripresa dei lavori su ext4, il filesystem successore di ext3 di cui Matteo ha già parlato in due diverse occasioni; nella sua mail il noto kernel hacker ha spiegato che i ritardi accumulati nello sviluppo e la mancata integrazione del lavoro svolto all’interno del kernel vanilla sono stati causati dall’eccessivo numero di persone che stanno partecipando allo sviluppo.
Henryx
08 mag 2007 - 10:14 - #2Sperem… Comunque sarebbe interessante se in ext4 integrassero il lavoro fatto in ext3cow che, come viene sottolineato anche dal nome, e` una variante di ext3
Enrico
foo
08 mag 2007 - 10:23 - #3Reiserfs e’ il top.. Ed e’ indiscutibile..
depaloan
08 mag 2007 - 10:24 - #4@foo
…finchè, dopo un reboot inaspettato, si dimentica di mezzo filesystem, lasciandoti un sistema che sembra un groviera. Nel mio caso sono tornato felicemente ad ext3.
foo
08 mag 2007 - 10:30 - #5Reiserfs non mi ha mai deluso, e non mi e’ mai successo che perdesse neanche 1Byte
Forse non ti sei mai trovato dei Giga in lost+found/ con il tuo amato ext3.
Ma non aver fretta, prima o poi ti capita, e capirai il perche’ della morte imminente di ext*fs
depaloan
08 mag 2007 - 10:36 - #6Beh, l’importante è che ognuno sia soddisfatto delle sue scelte indipendentemente da quali esse siano. O no?
foo
08 mag 2007 - 10:40 - #7Si certo..
ekerazha
08 mag 2007 - 11:00 - #8Il filesystem più prestazionale per Linux sembrerebbe attualmente XFS (es. http://www.debian-administration.org/articles/388 ).
ReiserFS tra le altre cose ha un tempo di mount a dir poco imbarazzante…
Personalmente direi che Ext3 è probabilmente il più stabile mentre XFS è probabilmente il più prestazionale. Certo se hai un “reboot inaspettato” con XFS ti potresti trovare catapultato alla settimana precedente :-D ma non a caso sono dotato di un UPS sul computer fisso (il portatile ha già la batteria).
Anche JFS sarebbe molto valido, ma ormai sembra abbandonato a se stesso (la mailing list è invasa dallo SPAM) e sembrerebbe soffrire alla lunga anche di gravi problemi di frammentazione (e il tool “defrag” per JFS non è stable… anche se al limite si potrebbe usare qualcosa tipo Shake).
Arael
08 mag 2007 - 11:07 - #9Mah…per esperienza personale mai avuto problemi con reiserfs.
Lo uso da sempre praticamente, ed è stabile come una roccia.
ekerazha
08 mag 2007 - 11:08 - #10Se cercate su Google trovate anche dei benchmark che contemplano il filesystem Ext4 (volevo aggiungere il link ad uno abbastanza completo, ma il filtro anti-spam di questo blog mi blocca il commento).
Xanderob
08 mag 2007 - 11:31 - #11@ ekerazha: Doh!
Ho / su JFS!
Ma come abbandonato?
Io mi ci trovo benino, nessun problema ad oggi.
ekerazha
08 mag 2007 - 11:39 - #12@Xanderob
Allora… tecnicamente non dovrebbe essere abbandonato, però se guardi la mailing list di JFS ormai c’è più spam che altro, insomma mi dà l’idea che il supporto sia un po’ in “decadenza”. Io personalmente sto migrando da JFS (anche io usavo JFS) a XFS.
nicosaturno
08 mag 2007 - 11:54 - #13io uso il reiser4 e devo ammettere che mi è capitato a volte di aver perso qualche file dopo un reboot inaspettato (il classico salto della corrente). Ma complessivamente mi ritengo soddisfatto, con il fsck.reiser4 ho sempre recuperato tutto.
Cmq per tutti gli amici di reiser :D vi linko questo howto ottimo per imparare a recuperare i file erroneamente cancellati (io avevo cancellato la mia intera cartella HOME)
http://antrix.net/journal/techtalk/reiserfs_data_recovery_howto.comments
(c’è un mio commento per recuperare i file con reiser4)
saluti
fedalmor
08 mag 2007 - 15:00 - #14Io ho ext3 per la root, XFS per la home ed NTFS (con FUSE/NTFS-3G) per la condividione con Windows… ho-vinto-qualche-cosa!? Nieeente! :)
hellview
08 mag 2007 - 16:09 - #15a proposito ma reiser ha ripreso lo sviluppo dopo essere stato scagionato ?
equilibrium
08 mag 2007 - 16:32 - #16@ekerazha: l’obligo di un UPS per XFS e’ oramai una leggenda metropolitana, retaggio del passato quando XFS era ancora in testing nel ramo 2.4 del kernel (quindi parliamo del 2002/2003, siamo nel 2007 oramai…); in caso di crash del l’OS, XFS non perde alcun dato perche’ fa uso di un meta-journal. Le eventuali perdite di dati derivano da due soli fattori:
1- uso della Write Cache dell’harddisk
2- corruzione dei dati in memoria
entrambi i casi non dipendo dal filesystem in uso (che sia XFS o altro), ma da problemi/impostazioni hardware. Basta usare memoria di qualita’ e disabilitare la Write Cache del proprio harddisk con i dovuti strumenti (hdparm/sdparm).
E’ ora che sta leggenda metropolitana per cui XFS/JFS necessitano di UPS (pena la perdita di dati in caso di crash) venga abbandonata, ma soprattutto si smetta di fare FUD e disinformazione in merito ai filesystem.
Paride
08 mag 2007 - 16:40 - #17A me e’ successo di perdere soltanto 80 Gb di roba con Reiserfs 3, quindi me ne sto alla larghissima…
aven
08 mag 2007 - 17:00 - #18Son sempre stato un sostenitore di XFS, come voi dicevo che era una roccia, testato su piu macchine etc etc. Poi ho abbandonato linux per un po di anni a livello desktop, mentre ho continuato a usare ext3 su server. Ripreso in mano il desktop da poco ho riprovato tutti i filesystem.
ext3, la base, solidissimo mai perso niente, opinione condivisa da quasi tutti, questo non è in discussione.
Reiser3, usato poco, non mi pareva di notare miglioramenti, miglioravo da una parte e peggioravo dall’altra.
reiser4 (comp. gzip), indubbiamente alcune operazioni è molto piu veloce di ext3. In altre molto meno. Carico gnome qualche secondo piu velocemente. Apro un file .avi da 1mb con totem e sento l’hdd macinare, tempo di apertura 4/5 secondi (inspiegabile), mentre con ext3 è sotto al secondo! E così anche in altri frangenti. Mentre di nuovo, openoffice si carica in minor tempo.
xfs, mi spiace dirlo non mi era mai successo in 2/3 anni, ma causa un crash del pc ho perso alcuni file. Purtroppo il problema con xfs è che i files restano ma diventano illeggibili. E non sai mai quanti files in giro per il filesystem sono corrotti. Ho dovuto reinstallare per essere sicuro dell’integrità del sistema.
ext4 (con extents) non ho notato grandi miglioramenti nelle apps che uso di solito. Morale, l’ho tolto subito. D’altronde è in sviluppo.
Nota bene: Il filesystem in linux è sempre stato come una guerra di religione, e non ho mai capito perchè! In rete ho trovato benchmark pro reiserfs che accusavano i mantainer del kernel di non includerlo perchè va *troppo più veloce* di ext3. Insomma si boicotta perchè va bene, e infatti il creatore di reiser è in prigione (frasi dell’autore, queste).
Insomma io ste cose non le capisco proprio.
equilibrium
08 mag 2007 - 17:15 - #19@aven: ecco bravo, avevo dimenticato di dirlo nel mio precedente post, un’altra leggenda metropolita su XFS/JFS e’ che si mangia parzialmente alcuni file di sistema, tipo fstab, mtab o altri. Mi spiace contraddirti, non c’entra nulla il filesystem, e’ un BEN NOTO bug di alcune (vecchie) versioni di hal e dbus. Il difetto si presenta comuqnue con tutti i filesystem, non solo XFS.
Xanderob
08 mag 2007 - 17:42 - #20@ equilibrium: consiglio al volo: XFS o JFS?
ekerazha
08 mag 2007 - 18:22 - #21@equilibrium
Leggenda metropolitana? Vai a dirlo al mio disco rigido quando non più tardi di 2 mesi fa ho dovuto fare un hard-reset del sistema e quando ho riavviato il PC il sistema era ritornato alla settimana precedente… ed è normale che sia così perchè è un “effetto collaterale” della strategia di delayed-allocation adottata da XFS (e anche da Reiser4).
Evitiamo di raccontare in giro certe cose quando non se ne ha un’esperienza personale.
equilibrium
08 mag 2007 - 19:55 - #22@Xanderob: dipende da quello a cui è destinato il filesystem, XFS e JFS sono equiparabili quasi in tutto. Per uso desktop, tra i due è sicuramente preferibile XFS perchè è meno avido di risorse rispetto a JFS. Se invece hai intenzione di usare OpenMosix o altro sistema di clustering è preferibile JFS perchè è maggiormente stabile e performante rispetto ad XFS (va da se che se stai realizzando un sistema cluster serio da mettere in produzione, allora non userei ne XFS ne JFS, ma Lustre che è il top della gamma). Negli altri ambiti sono equiparabili.
@ekerazha: vedo che non hai capito una fava di quello che ho scritto, ti rimando alla lettura delle FAQ della SGI –> http://oss.sgi.com/projects/xfs/faq.html
in cui viene spiegato molto bene il problema della Write Cache e della perdite di dati in seguito ad un crash. In modo particolare leggiti la FAQ “Why do I see binary NULLS in some files after recovery when I unplugged the power?” e seguenti, specialmente la parte che recita:
“Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. **This causes problems for XFS and journaled filesystems in general** because they rely on knowing when a write has completed to the disk”
Il delayed-allocation di XFS non è la causa della perdita di dati, i fattori sono altri e riguardano le “write hardware barrier” (che sono presenti nel kernel linux solo dalla versione 2.6.18 e successive) non attive, il mancato uso di O_SYNC/O_DIRECT in fase di mounting (che dal kernel 2.6.21 è abilitato di default, mentre per le versioni precedenti va abilitato manualmente con l’apposita opzione) e l’uso della Write Cache *SENZA* un UPS. La leggenda metropolitana nasce proprio quando le persone leggono “serve un UPS” e recepiscono tale informazione come soluzione del problema, quando in realtà la soluzione è: DISATTIVARE la Write Cache dell’harddisk (che è una funzione hardware dello stesso e non del filesystem!!) e se sono supportate, usare le Write Barrier Hardware. Se configuri XFS/JFS in modo corretto, stai sicuro che i dati non li perdi anche se attacchi/stacchi l’alimentazione a caldo ripetutamente.
Può capitare che si corrompano i dati dei buffer del journaling e dei metadatas i quali sono contenuti in RAM, e quindi in caso di crash ti puoi ritrovare con parecchi file corrotti. Fino a prova contraria però la RAM non ha nulla da spartire con il filesystem, e se qualcosa si corrompe è solo per un problema hardware (della RAM) dovuto a scarsa qualità dei materiali, o al software che fa porcate in fase di allocazione/deallocazione (vedi bug di HAL precedentemente citato).
Ovviamente non contesto il fatto che tu abbia avuto delle perdite di dati, o che XFS/JFS ne siano soggetti. E’ ovvio che ci sono, XFS/JFS non ne sono immuni, ma sono comunque eventi rarissimi, e parlo delle *vere* perdite/corruzioni di dati. Nel caso specifico di XFS una corruzione generata da se stesso la si nota perchè il filesystem entra in modalità ‘freeze’, generando l’errore 990 in fase di mount (ti viene impedito di montare la partizione fin quando non togli la flag freeze). Anche JFS ha una feature analaga chiama modalità ‘dirty’ ed entrambe servono per evitare che l’idiozia dell’utente favorisca il propagarsi della corruzione sul resto del filesystem. In queste specifiche situazioni SI, il filesystem ha generato corruzione e/o perdite di dati, in tutti gli altri casi, non ne è responsabile il filesystem ma altri fattori (che come ho spiegato sopra ricadono per il 99% sulla questione delle Write Cache e della RAM bacata). Da notare che il problema della Write Cache non è specifica di XFS o JFS, ma qualora non lo avessi ancora capito, si presenta su QUALSIASI filesystem di tipo journaling perchè tale feature dell’harddisk vanifica il journing stesso in determinate circostante (crash, interruzione dell’alimentazione).
citaz: “Evitiamo di raccontare in giro certe cose quando non se ne ha un’esperienza personale.”
Guarda che le cose che ho scritto mica me le sono inventate, ti invito a leggerti il TechPubs di SGI (in particolare l’ XFS Ondisk Format) e la documentazione ufficiale di IBM DeveloperWorks, dove potrai trovare riscontro a tutto ciò che ho riportato. Sicuramente sono testi molto più affidabili di quanto viene riportato invece da wikipedia (da cui, IMHO, presumo tu abbia tratto le tue informazioni).
(scusate la lunghezza eccessiva del post)
ekerazha
08 mag 2007 - 20:31 - #23@ekerazha
Se l’attendibilità delle cose che hai detto fosse proporzionale alla lunghezza di questo tuo post, probabilmente rischieresti di scrivere qualcosa di sensato.
La “write cache” è solo uno degli elementi che possono portare alla perdita di dati in caso di “interruzione imprevista” (tra l’altro la sua disabilitazione penalizza anche leggermente le prestazioni, ma va be’).
L’effetto collaterale della delayed-allocation (allocate-on-flush) è un problema concreto, in quanto questa strategia consiste (per ragioni di performance e per organizzare più efficientemente i dati su disco e diminuire la frammentazione dei dati) nel non inviare immediatamente i dati al disco rigido per la scrittura, ma di cacharli per quanto possibile in memoria centrale. Essendo la memoria centrale una memoria di tipo volatile, risulta evidente che in caso di blackout i dati che contenesse svanirebbero e quindi eventuali dati che non fossero ancora stati allocati sul disco rigido risulterebbero persi e questo è vero indipendentemente dalla bontà dei moduli di RAM (se poi i moduli fossero danneggiati è *lapalissiano* che potranno esserci problemi: come già detto le cause possono essere molteplici).
Questo è facilmente riscontrabile anche nei fatti: come già detto è capitato che in seguito ad una “interruzione imprevista” i dati del mio disco con file-system XFS fossero stati “catapultati” allo stato in cui si trovavano alcuni giorni prima. Sicuramente la cache dell’hard disk non è così capiente da contenere il lavoro di intere giornate, al contrario della memoria centrale, quindi è del tutto evidente che la perdita sia originata dall’utilizzo della delayed-allocation.
Nessuno dice che tu ti sia inventato cose, semplicemente le tue conoscenze sono parziali ed incomplete (e tratte da wikipedia, coda di paglia? ;) ). Forse oltre a leggere le FAQ sul sito acquisendo una conoscenza superficiale dell’argomento, dovresti studiarti innanzitutto il funzionamento basilare di un file-system (e di un hard disk) ed in seguito procedere allo studio del codice relativo al file-system XFS all’interno del kernel.
Bye.
ekerazha
08 mag 2007 - 20:44 - #24“quindi è del tutto evidente che la perdita sia originata dall’utilizzo della delayed-allocation”
Per pignoleria faccio una precisazione: “originata *prevalentemente*”: pochi MB avrei potuto perderli anche per la write cache (che poi il principio all’origine della perdita dei dati è la medesima dato che anche la cache dell’hard disk è una memoria volatile), ma sicuramente non la mole di dati totale che è andata persa nel mio caso (per i suddetti motivi).
aven
09 mag 2007 - 09:01 - #25Riproverò XFS con la write cache disabilitata, ma ti assicuro che ne ho di esperienza con detto filesystem, e qualcuno lamentava i problemi ben prima che esistessero hal e dbus. Per quanto mi riguarda li ho riscontrati solo ad anni di distanza…
Tutto quello che dico è che ext3 non mi ha mai giocato di questi problemi, ed attualmente lo uso su 5 desktop e una decina di server…. ;-)
ekerazha
09 mag 2007 - 10:19 - #26@aven
Infatti ext3 non usa la delayed-allocation ;-)
ekerazha
09 mag 2007 - 10:33 - #27Tra l’altro la write cache essendo una memoria cache dell’hard disk, non ha molto a che spartire con il file-system, quindi una piccola quantità di dati è perdibile a causa della write cache su praticamente qualsiasi file-system (e non solo su XFS). Su XFS se ne possono perdere molti di più (in caso di interruzione imprevista) appunto per la delayed-allocation (scusate se mi ripeto :) ma è stata spacciata la write cache come un qualcosa che sarebbe “specializzato” nel nuocere a XFS).
equilibrium
09 mag 2007 - 15:29 - #28@ekerazha: non capisco se ci sei o ci fai, comunque nella mia precedente risposta ti ho invitato non solo a leggere le FAQ della SGI ma anche il TechPub (oltre all’ IBM DeveloperWorks), cosa che non hai fatto, altrimenti sapresti che la delayed-allocation non ha nulla a che vedere con la RAM (cosa che sostieni tu) in quanto passa i dati direttamente al meta-journal che è un file che risiede sull’harddisk e non in RAM. In RAM ci stanno solo i buffer temporanei dei processi di I/O e di allocazione (già qui dimostri di non sapere una fava su come funziona il filesystem XFS di suo, e ti *re-invito* a leggerti l’XFS Ondisk Format che è disponibile sul sito della SGI). In questi buffer transitano ANCHE i metadata, ma non restano residenti in RAM per giorni come vorresti far credere tu, ma ci restano per un tempo relativamente molto breve (di default è MASSIMO 30sec).
Ora, che tu dica, che dopo un crash parecchi tuoi dati sono tornati “indietro nel tempo” di una settimana è pure follia. Cioè tu vorresti dirmi che hai creato un file il giorno X, e nei giorni successivi ha accesso/spento il tuo sistema svariate volte (quindi i tuoi dati sono stati flushati dal file di log del meta-journal e scritti su disco) ma dopo un crash del sistema, il filesystem ha deciso arbitrariamente di ripristinare la versione del file X a quella di qualche giorno prima? O_o
E come è possibile che ciò sia avvenuto? il meta-journal, una volta che ha scritto le nuove modifiche (metadata) nel file, non tiene nessuna copia dei metadata già scritti. Anche prendendo per buona la tua tesi sui metadata costantemente cachati in RAM (che comunque non è assolutamente vera!!), hai comunque spento e acceso il tuo pc più volte in quei giorni, quindi è impossibile che ci fosse ancora qualche “residuo” in RAM. Ora tu potresti anche rispondermi sostenendo che in quei giorni non hai mai acceso e spento il PC, bene, se così fosse il meta-journal non tiene i suoi log per così tanto tempo, perchè di default il flush dei dati avviene ogni 30sec (vedere documentazione allegata al kernel, in particolare il parametro sysctls: fs.xfs.xfssyncd_centisecs) quindi in 48ore i tuoi dati sono stati flushati e il metajournal non ne ha più traccia già da parecchio tempo. E non puoi nemmeno dire di avere impostato valori di syncd superiori alle 24H, perchè il massimo che XFS consente è un delay di 2 ore. Non ha senso quello che hai scritto, avrebbe senso se i tuoi file dopo il crash fossero diventati illegibili (totalmente o parzialmente) o fossero spariti dagli inodes. Questo SI’ che sarebbe possibile, ma non che il contenuto dei tuoi dati è tornato ad essere quello di qualche giorno prima. Ciò non può accadere per nessun filesystem, soprattutto a quelli dotati di meta-journal, al massimo avresti perso le ultime 2 ore di modifiche (impotizzando valori di syncd custom), o per dirla nei tuoi termini, i dati “sarebbero tornati indietro di due ore”. Ma da qui a dire che “l’intero sistema è tornato indietro di 1 settimana” è pura follia.
Mi piacerebbe molto sapere che motivazioni tecniche e plausibili ci sono alla base della tua teoria tali da imputare ad XFS quanto da te asserito, soprattutto considerando che, come ho spiagato sopra, ne il meta-journal ne il sistema di syncd ne tanto meno il meccanismo di delayed-allocation possono provocare il TUO problema perchè AL MASSIMO possono gestire metadata di 2 ore. Siccome di motivazioni plausibili non ce ne sono (io una ce l’ho, ma evito per non generare un altro flame), e considerando il fatto che mi sono stufato di continuare questa discussione sulla base delle tue patetiche argomentazioni, ti considero semplicemente un troll e d’ora in avanti ti ignorerò.
E ti ripeto: non discuto sul fatto che hai avuto problemi di perdite di dati (nessun filesystem è immune da problemi e non ho mai scritto che XFS è esente da perdite di dati), ma dubito fortemente che il TUO SPECIFICO CASO sia imputabile al filesystem (avrei asserito le stesse argomentazioni anche se tu avessi citato un altro filesystem al posto di XFS).
citaz: “Forse oltre a leggere le FAQ sul sito acquisendo una conoscenza superficiale dell’argomento, dovresti studiarti innanzitutto il funzionamento basilare di un file-system (e di un hard disk) ed in seguito procedere allo studio del codice relativo al file-system XFS all’interno del kernel”
non ti preoccupare che sono tutti argomenti che conosco perfettamente, invece lo stesso non si può dire di te visto che le risposte che dai non fanno altro che confermare una TUA conoscenza superficiale degli argomenti (dici pure di usare XFS solo da pochi mesi…), stravolgendo e riportando concetti (mentendo palesemente, vedi la tua teoria sui metadata) al solo scopo di avere ragione a tutti i costi e fare FUD. Ora sei anche libero di insultarmi se lo ritieni.
Luca 6,41- 42: “Perché guardi la pagliuzza che è nell’occhio del tuo fratello, e non t’accorgi della trave che è nel tuo? Come puoi dire al tuo fratello: Permetti che tolga la pagliuzza che è nel tuo occhio, e tu non vedi la trave che è nel tuo? Ipocrita, togli prima la trave dal tuo occhio e allora potrai vederci bene nel togliere la pagliuzza dall’occhio del tuo fratello”
ekerazha
09 mag 2007 - 17:10 - #29@equilibrium
Dalla tua risposta risulta ancora una volta evidente che tu non abbia la minima cognizione di causa relativamente al funzionamento di XFS e della delayed-allocation (e a questo punto direi anche del journaling).
Se ti fossi documentato veramente (e non superficialmente come hai fatto) e avessi letto la documentazione di SGI, avresti incontrato materiale come questo (liberamente tratto da un paper di SGI sulla scalabilità di XFS):
“Delaying Allocation
One of the key features of XFS in allocating files contiguously is delayed file extent allocation. Delayed allocation applies lazy evaluation techniques to file allocation. Rather than allocating specific blocks to a file as it is written in the buffer cache, XFS simply reserves blocks in the file system for the data buffered in memory. A virtual extent is built up in memory for the reserved blocks. Only when the buffered data is flushed to disk are real blocks allocated for the virtual extent. Delaying the decision of which and how many blocks to allocate to a file as it is written provides the allocator with much better knowledge of the eventual size of the file when it makes its decision. When the entire file can be buffered in memory, the entire file can usually be allocated in a single extent if the contiguous space to hold it is available. For files that cannot be entirely buffered in memory, delayed allocation allows the files to be allocated in much larger extents than would otherwise be possible.
Delayed allocation fits well in modern file system design in that its effectiveness increases with the size of the memory of the system. As more data is buffered in memory, the allocator is provided with better and better information for making its decisions. Also, with delayed allocation, short lived files which can be buffered in memory are often never allocated any real disk blocks. The files are removed and purged from the file cache before they are pushed to disk. Such short lived files appear to be relatively common in Unix systems [Ousterhout85, Baker91], and delayed allocation reduces both the number of metadata updates caused by such files and the impact of such files on file system fragmentation.”
In cui risulta chiaramente esplicitato (come ho detto io) che i dati vengano cachati in memoria centrale.
In secondo luogo, come già detto mi è successo (e questo è un dato di fatto incontestabile in quanto materialmente accaduto) che in seguito ad una “interruzione imprevista” provocata da un hard-reset, al riavvio il contenuto di molti file fosse ritornato quello di circa una settimana precedente: lo stato globale dei dati era consistente, ma come già detto i dati hanno fatto un salto nel passato (per i motivi già spiegati). Sottolineo il fatto che il computer in quei giorni è sempre rimasto acceso (solitamente il mio computer rimane acceso sempre).
Sembri fare un po’ di cofusione tra metadata journaling e block journaling: XFS utilizza solo il metadata journaling ed il fatto che i metadati vengano flushati abbastanza frequentemente non risolve del tutto la situazione, poichè i dati veri e proprio ed il metadata journal possono essere benissimo out-of-sync ed abbinando questo alla delayed-allocation la minestra è pronta.
Concludendo, la tua “conoscenza dell’argomento” non mi sembra risaltare particolarmente, ma stai tranquillo che insultare (come hai fatto tu dall’inizio) non sarebbe nel mio stile: dalla mia ho la realtà dei fatti. Comunque per tua informazione utilizzo XFS da circa 2 anni, con l’eccezione di qualche mese trascorso in compagnia di JFS su alcune macchine (ammesso che questo c’entri qualcosa: bastasse usare qualcosa per sapere come funziona…).
P.S.
Quel passo del Vangelo ti calza a pennello.
Henryx
11 mag 2007 - 16:49 - #30@ekerazha:
Il tuo problema e` atipico, in quanto sembra che tu non abbia fatto il sync dei dati per tutto il periodo per cui e` stato acceso il pc (cosa abbastanza strana, visto che dovrebbe essere fatto ogni tot secondi)
Enrico
ekerazha
11 mag 2007 - 18:19 - #31@Henryx
Ogni quanto ti risulta che venga fatto?
equilibrium
12 mag 2007 - 19:28 - #32citaz: Ogni quanto ti risulta che venga fatto?
@ekerazha: te l’ho scritto nei miei post precedente piu’ di una volta:
il sync time di XFS e’ dato dal parametro sysctl: fs.xfs.xfssyncd_centisecs
se guardi la documentazione del kernel (Documentation/filesystem/xfs.txt) trovi scritto che per quel parametro di sysctrl, il valore di default e’ 3000, cioe’ 30sec, e al MASSIMO si puo’ impostare 720000 ovvero 2 ore. Il default e’ 30 sec e oltre le 2 ore non si puo’ forzare il lease time del syncd di XFS, quindi avere i buffer in RAM per piu’ del tempo impostato dal syncd non e’ possibile.
ekerazha
13 mag 2007 - 00:37 - #33@equilibrium
Evidentemente nemmeno la lettura è il tuo punto forte: quel parametro indica il sync time dei metadati, non dei “dati”, dei metadati.
ekerazha
24 mag 2007 - 22:19 - #34Tra l’altro anche ad un mio compagno di corso all’università, in seguito ad un blackout del suo sistema (Gentoo Linux su XFS), lo stato del disco è tornato a circa 1 giorno e mezzo prima… che dire, questi avvenimenti “impossibili” sembrano accadere abbastanza spesso.
hellview
27 mag 2007 - 19:32 - #35cmq reiser li sotterrerà tutti :)
Fed7
31 mag 2007 - 19:58 - #36Se uscisse anche per Linux :(
ZFS li seppellirebbe tutti.