Dopo due mesi intensi di lavoro, Linus Torvalds e il team di sviluppatori dietro al Kernel Linux hanno annunciato il rilascio della versione 2.6.19. Tra le novità di questa versione troviamo: GFS2 (filesystem utilizzato in ambito clustering), Ecryptfs, una prima versione sperimentale del filesystem EXT4 (destinata agli sviluppatori), il supporto per l’architettura Atmel AVR32 e molto altro.
[Via | osnews.com]
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.
Riccardo
30 nov 2006 - 11:33 - #1Bella notizia sopratutto per i cluster di macchine virtuali XEN
dgali
30 nov 2006 - 12:42 - #2Ma non hanno inserito il supporto in scrittura al NTFS (ntfs-3g)?
devon
30 nov 2006 - 12:46 - #3@ dgali:
Il progetto cui ti riferisci, ntfs-3g, è un software user-space, non kernel space.
Funzione appoggiandosi a FUSE, l’infrastruttura kernel-space per i file-system in user-space. Chiaro no? :)
equilibrium
30 nov 2006 - 13:29 - #4GFS2 non è sta gran meraviglia comunque, senza togliere nulla alla RedHat e al suo operato, ma in genere, in ambito clustering si usa Lustre(TM) (–> www.lustre.org). con un unico software si hanno le stesse funzionalità di GFS2 + DRBD + NDB + NFS + LVM2 + EVMS, ma senza i problemi tipici di NFS/DRBD/LVM e dello Storage Sharing di GFS2
dgali
30 nov 2006 - 14:26 - #5@devon:
Hai ragione!
grazie.
P.S.: xchè (quasi?) tutti gli altri FS li realizzano in kernel-space? Non è più sicuro farli in user?
Ok le prestazioni ma ormai ci sono centinaia di FS in linux…
mad_max
30 nov 2006 - 19:36 - #6x Dgali
Ho provato ntfs-3g ed è decisamente lento (persino in lettura) impegnando la CPU al 100%. Questo è purtroppo il peggior difetto degli fs implementati in userspace.
Sicuramente è più sicuro fare tutto in userspace e lasciare nel kernel solo le funzioni strettamente necessarie. Un sistema siffatto viene detto ” a microkernel “. Linux invece è un kernel monolitico, cioè dove tutte le funzionalità (o quasi) girano in kernel space.
Quale sia la soluzione migliore non è facile da stabilire e in generale dipende dall’utilizzo che se ne vuole fare. Di sicuro una prerogativa del microkernel è quella di un grande margine di stabilità nel senso che se un servizio del kernel si dovesse inceppare, può semplicemente essere riavviato (perchè molto semplicemente è un processo).
Mentre con un kernel monolitico un solo bug in un servizio (anche il + inutile) può bloccare l’intero sistema. Il rovescio della medaglia: un kernel monolitico è molto + facile da realizzare e mantenere rispetto ad un microkernel (con servizi connessi).
Se cerchi in rete puoi trovare una famosissima discussione tra il maestro dei microkernel Tanenbaum (http://www.cs.vu.nl/~ast/) ed il suo allievo Linus Torvald (sostenitore della filosofia del kernel monolitico).
Paolo Mainardi
01 dic 2006 - 16:33 - #7La lentezza del fare in Userspace in questo caso è da delegare a Fuse, è il costo da pagare per non rimettersi a scrivere da soli un interfaccia User -> Kernel Space, inoltre Fuse non ha documentazione, quindi è facile trovarsi a scrivere codice che oltre ad non essere per niente ottimizato, rischia di rompere qualcosa in kernel space, parlo per esperienza personale, comunque Fuse rimane un ottimo progetto, ma non è assolutamente da considerare un sistema affidabile tanto da considerare l’inclusione di FS nel kernel tree, sviluppati utilizzando proprio Fuse.
Paolo
dgali
05 dic 2006 - 12:59 - #8Si conosco le differenze tra un sistema a microkernel e un sistema a kernel monolitico e la relativa discussione tra Linus e Tanenbaum.
Io però non intendevo dire che Linux debba diventare un microkernel ma semplicemente che vista la possibilità di fare FS in user space fosse utile e sensato passare in user-sapce alcuni FS oggi supportati in kernel-space, soprattutto i meno utilizzati e comunque “non nativi” (Es.: FAT e NTFS).
Se invece il problema è proprio la velocità (e come dice Paolo in particolare a causa di FUSE) capisco il motivo per cui i FS rimangono in kernel-space.
A qs punto non mi rimane che sperare che FUSE faccia progressi e venga inserito nel kernel ufficiale così che vengano riscritti i FS in user space!
Ciao, dgali.