L’interessante ipotesi, che era stata avvallata dagli sviluppatori Fedora nei giorni scorsi, è stata messa da parte nella giornata di ieri dallo stesso team. Anche per questa voltà, per vedere Btrfs come file system di default dovremo attendere la versione successiva di Fedora, in questo caso la versione 18; come già accaduto con Fedora 16, nella prossima versione troveremo Ext4 come FS di default.
La causa principale di questa non introduzione di Btrfs è la mancata integrazione tra il file systm e Anaconda, l’installer di Fedora; questo infatti non supporta ancora la modifica interattiva dei dischi con Btrfs. L’impossibilità di coesistere di Anaconda e Btrfs è solamente uno dei motivi di questa non adozione, infatti il mancato rilascio di btrfsck potrebbe essere l’altro motivo. La storia si ripete, anche in Fedora 16, Btrfs non era stato adottato di default a causa della mancanza di una versione stabile di btrfsck.
Il team di Fedora non ha esplicitamente annunciato l’abbandono di questo progetto, ma all’interno del suo ciclo di sviluppo, una svolta così importante non potrebbe che essere definitiva.
Via | The H Online
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
ekerazha
18 feb 2012 - 10:56 - #1btrfsck sembrerebbe il nuovo Duke Nukem Forever
Shiba
18 feb 2012 - 12:00 - #2La prossima notizia su Fedora sarà che slitta la data del rilascio? :D
tremore-essenziale
18 feb 2012 - 12:39 - #3mi sembrava… a quelli di Fedora piacerà anche sperimentare, ma btrfs è ancora troppo acerbo, soprattutto come utility di contorno
forse per la 18
blackibiza84
18 feb 2012 - 18:56 - #4btrfs é davvero penoso in prestazioni…ha senso solo se si utilizza un disco SSD, mentre con un HD tradizionale lo trovo lento (usato su CrunchBang)
tangram
18 feb 2012 - 20:14 - #5C’è un errore ortografico. Non è “Brtfs” ma “Btrfs” (B-tree FS).
Henryx
18 feb 2012 - 22:23 - #6#4
Ma nemmeno, visto, che si ha a disposizione ext4, che e` sicuramente piu` stabile
Enrico
Kim Allamandola
19 feb 2012 - 23:42 - #7@Henryx #6
Prova btrfs con
compress,discard,ssd
su un ssd qualunque e capirai che ext4 non fa per te, prova il vecchio reiser
su un disco a piattelli e vedrai che l’ext4 non fa per te. Ad un utente di
questo blog il discorso non piace ma se hai un po’ di tempo per provare le
due install vedrai la differenza!
Sulla stabilità… L’ho in produzione dall’estate scorsa, ho solo avuto una
volta un problema di esaurimento di spazio per i metadati su una partizione
veramente piena, per il resto nessun problema :-)
Cesoia
20 feb 2012 - 18:51 - #8Considerare XFS seriamente e’ sempre una bestialita’ cara fedora?!
Kim Allamandola
20 feb 2012 - 22:16 - #9@Cesoia #8
XFS è molto comodo per alcune cose, ma è troppo lento per un desktop…
È pure superato per le features che aveva “uniche” (es. gli snapshot) da
btrfs che anche sui piattelli è molto più veloce nei tree “grossi”. L’XFS ti
va bene se fai montaggio video con un backend FC ma non per altro da parecchi
anni a questa parte…
Cesoia
21 feb 2012 - 15:41 - #10@Kim Allamandola
Bah sul fatto della lentezza sui desktop,adesso,non dovrebbe piu’ esser un problema.Almeno a quanto dice il mantainer RH di XFS,Chinner.XFS oggi,ha piu’ di 10 anni di anzianita’ sotto il pinguino,e’ attivamente mantenuto e migliorato ed e’ globalmente prestazionale.Ovvero un filesystem assolutamente maturo per esser utilizzato in ambito enterprise e non solo.
Non si capisce quindi,l’atteggiamento vergognoso di Fedora/RH nel mettere (costantemente) in secondo piano tale scelta e proporre come default (anche in ambito Enterprise) l’ultimo arrivato,un filesystem giovane,bacato e carente in tutto!
Vogliono copiare Oracle con ZFS? Si prendano il tempo necessario per svilupparlo.Non si improvvisano soluzioni solo per questioni di marketing.Btrfs non e’ pronto e non sara’ tale per diverso tempo.
Sara’ anche il futuro ma gli ambienti di produzione non perdonano la gioventu’ di un prodotto.
Non capisco veramente certi atteggiamenti……
Kim Allamandola
21 feb 2012 - 17:32 - #11@Cesoia #10
Personalmente ho usato xfs dai tempi del 2.4.x (poco dopo la sua inclusione)
sino ai primi 2.6 (quando ho proprio lasciato GNU/Linux), di evoluzione né ho
vista poca e le performance a livello di tree traversing ed in particolare di
gestione dell’allocazione dei metadati sono sempre state pessime. Il port è di
superba qualità e il supporto di xfsprogs* è fantastico ma l’evoluzione è ferma
da anni: erano stati fatti grandi progetti nei primi anni 2000 parlando del
supporto a cxfs, della dmapi ecc ma finita l’SGI sono finite anche le
ambizioni… L’ho riprovato l’estate scorsa tornando a GNU/Linux e mi sono
decisamente stufato… È una delle tante cose buone di Irix che non ha trovato
un suo futuro IMO…
Sul Btrfs c’è qualcosa da dire: è sicuramente di un’era passata rispetto allo
zfs, è sicuramente scritto in stile Oracle (non ex-SUN) ma è l’unico fs Linux
al momento che supporti in maniera usabile snapshot, compressione, resize in
tutti e due i sensi e trim. Sugli SSD va bene in termini di performance, nel
suo complesso è ragionevolmente stabile, è appena uscito btrfsck ed è in giro
una patch che lo rende più reattivo del 5-10% (stando a Phoronix), ’somma la
via IMO è: riscrivere il VFS prendendo spunto da IllumOS/ZFS e nel frattempo
tenere btrfs vivo e vegeto…
Riscrivere il VFS pare non sia in calendario, gli sviluppatori GNU/Linux sono
gente un po’ permalosa e non gli piace che altri trovino soluzioni migliori
delle loro (IllumOS ed il vecchio Irix solo come esempio) specie se sono di
gente UNIX…
Cesoia
22 feb 2012 - 12:09 - #12@Kim Allamandola
Si anch’io ho cominciato ad usare XFS insieme a ReiserFS e JFS (per poi usare solo quest’ultimo) intorno l’anno 2000 procedendo al patching dei vari kernel vanilla.E’ vero anche che per i primi anni non si e’ proceduto a variazioni nel codice di XFS se non per migliorare l’inclusione nel nuovo derivato UNIX senza affrontare la questione prestazioni.L’algoritmo del delayed logging che poi sempre secondo Chinner e’ il responsabile primo ed unico dei miglioramenti di performance del filesystem e’ entrato nel tree solo dal 2.6.35 (se non erro) ed e’ allo studio dal lontano 2005.L’inclusione dei tool di gestione di XFS e del modulo di kernel in RHEL e’ stato *preteso* da HP,visto che i problemi di ext* in scalabilita’ erano (e sono)evidenti a tutti. Insomma e’ chiaro che se fosse per RH,XFS sarebbe un ricordo in favore di un filesystem dalle potenzialita’ dubbie come ext*.Non parliamo poi,della ciliegina sulla torna di Btrfs,che si pretenderebbe di default gia’ oggi con Fedora!
Ma stiamo scherzando? In ambito enterprise? o questi non sanno esattamente cosa stanno forzando oppure mettono il marketing prima di *ovvie* considerazioni tecniche.In verita’ non sarebbe la prima azienda a farlo,ma se permetti certe bestialita’ te le aspetti da microsoft non da RH con uno UNIX di mezzo.
“erano stati fatti grandi progetti nei primi anni 2000 parlando del
supporto a cxfs, della dmapi ecc ma finita l’SGI sono finite anche le
ambizioni… ”
Vero anche questo ma converrai con me che se non si sponsorizza una tecnologia fai anche fatica a promuovere progetti collegati.Li’ sponsorizzava la vecchia Silicon ma oggi dovrebbe farlo la comunita’ linux sotto chiare motivazioni (anche economiche) dei Big del settore come RH,IBM ed HP.
Non credo francamente che ext2 si sarebbe evoluto molto a lungo se non fosse stato per l’aiutino di RH….(e visto cio’ che ne’ e’ uscito,sono stati pure vigliacchi ad imporlo escludendo dall’installer altre scelte sotto discutibili questioni tecniche).
Comunque,fai bene a rimarcare aspetti tecnici del Btrfs che altri fs sotto linux non hanno.E’ la realta’.Ma per l’enterprise sotto linux, cio’ riguarda il futuro non il presente che deve fare i conti con la scalabilita’ e la maturita’ del codice,caratteristiche queste, che mal si adattano ad ext4.
Vedremo.
Kim Allamandola
22 feb 2012 - 20:57 - #13@Cesoia #12
Su ext* siamo daccordo, del resto è daccordo pure uno dei suoi principali
sviluppatori, Theodore Ts’o, pare che in questi lidi solo un tal ekerazha
non la pensi come noi :-> Idem sono daccordo sui comportamenti di RH, non
solo per Gnome Shell di cui s’è flame-ato parecchio in questi tempi, del
resto c’è qualche motivo se me ne andai ai tempi della Fedora Core 4…
Sui miglioramenti di XFS però non ho riscontro, sono ritornato su GNU/Linux
l’anno scorso dopo anni di FreeBSD prima e Solaris/Opensolaris poi, la prima
cosa che ho fatto è installare un desktop personale col mio vecchio solito
schema (4 vol. lvm con / e /home in XFS) bé il risultato è stato penoso…
Sono passato al reiser ed è stato come cambiare dal giorno alla notte! Poi
passato agli SSD ho provato per curiosità ext4 e mi ha deluso, sono passato
allora a btrfs e mi ci son trovato, nulla di paragonabile allo zfs, compress
a parte che è più “leggera”, in particolare se lo monti con discard hai quasi
un raddoppio delle performance; gli aggiornamenti più recenti han aggiunto
l’opzione ssd che si aggiunge da sola e non mi pare faccia nulla di che ed
anche space_cache che di nuovo non mi da differenze significative…
Sul fatto che il btrfs sia immaturo per un uso enterprise… Boh, io per i
pochi desktop con ssd lo trovo assolutamente indicato, la stabilità che un
desktop necessita è più che presente; lato server resto su Nexenta maledicendo
Oracle, quegli sviluppatori GNU/Linux che per un motivo o per l’altro non
guardano fuori dal loro giardino ed anche Canonical che non ha provato ad
assumere un po’ di gente di IllumOS per almeno tentare di spingere
Debian/GNU/Solaris (ovvero Nexenta) e aprire nuovamente le porte ad uno unix
con un desktop moderno dove la Sun s’è dovuta fermare e correggendo i suoi
errori…
Sulle features infine… Bé se devo essere sincero ritengo l’enterprise di
oggi staccata dal mondo reale ed insostenibile. Altro che filesystem! Siamo
nel 2012, i server più diffusi sono ancora con 1/2/4 porte Gb e bon ma si
inizia sul serio a vedere link 10Gb/s, 40Gb/s, 1Tb/s, finalmente s’è iniziato
a dire che ci vuole fibra in ogni rack… Ogni produttore spreca risorse nel
tentativo di aggirare i limiti dell’architettura x86 (Drac, iLO, RSA, …) e
non abbiamo ancora un fottuto installer moderno, né in locale né sopratutto
per il deploy remoto! Canonical ha mezzo iniziato Orchestra che a sua volta
wrappa Cobbler di RH, varie istituzioni han fatto soluzioni casalinghe scomode
o parecchio scomode (es FAI&c) tanto siamo sempre a litigare con preseed e
kickstart che sono resti di un’altra era. Idem si sprecano risorse per app
da Spacewalk o Landscape sin giù al vecchio Webmin e si continua a restare
fermi a sistemi di pacchettizzazione dell’anteguerra.
C’è un problema: capire cosa vuol dire EVOLUZIONE, smettere di continuare a
costruire soluzioni improbabile per mantenere vecchie strutture che sono
evidentemente da rifare. Sino a che non si entrerà in questa forma mentis
ogni mini-novità sarà solo una rottura di scatole ed un po’ di benzina per
flame vari…