View Full Version : scelta filesystem
Che filesystem conviene usare per un fileserver?
I file si possono raggruppare in questo modo per ordine di grandezza:
80% 300mb a 400mb
15% 600mb a 800mb
5% > 1GB
Mediamente il server verrà "svuotato" ogni 4/5 mesi, però vengono caricati 3/4 files al giorno per un intervallo di tempo pari a 6 giorni per settimana.
darkbasic
18-11-2007, 15:33
xfs o ext3
Non ricordo bene quali dei due si comporti meglio con file di grosse dimensioni, ma in ogni caso siamo lì.
Sicuramente sono entrambi estremamente affidabili.
Nel general purpose xfs è leggermente più veloce, ma in un fileserver fa ben poca differenza.
Tieni presente che usando ext3 un 5% dello spazio libero verrà sacrificato a suo uso e consumo.
ok grazie, avevo letto un articolo ed infatti anche lì si parlava di XFS. Ed il 5% di spazio dedicato per l'fs è troppo :asd:
Il 5% rappresenta lo spazio riservato a root per continuare a gestire il sistema anche in caso di riempimento del disco rigido principale. Se non hai file di sistema su quel discopuoi tranquillamente impostarlo a 0 usando tune2fs
ciao ;)
Xfs per file di quelle dimensioni
Xfs per file di quelle dimensioni
xfs è velocissimo ma come siamo messi a stabilità e "robustezza"?
provai xfs una sola volta un anno fa e, dopo un reset della macchina, il filesystem era completamente disintegrato :eek: :muro:
con ext3 o reiserfs mai successo...
mi piacerebbe tornare a xfs ma vorrei sapere se han fatto progressi per ovviare al problema di cui sopra.
PS: è possibile vedere un filesystem xfs da windows? con ext3 si può ma con xfs non so...
Questo driver può leggere Ext, XFS e Reiser da windows http://www.crossmeta.com/crossmeta.html.
XFS non ha nessun problema di stabilità in se, solamente il fatto di tenere parecchio i dati in cache prima di scriverli lo rende più sensibile di altri agli arresti improvvisi del sistema.
XFS ha giustamente la fama di essere un file system ad alte prestazioni, ma molte delle sue potenzialità vanno abilitate e configurate a mano, come l'I/O real time, perche possa essere sfruttato al massimo e si senta la differenza. Se uno non sa fare il tuning tanto vale che usi l'Ext3.
darkbasic
18-11-2007, 20:38
Dai test che ho fatto finora l'unico filesystem che si è rivelato essere decisamente più veloce degli altri è stato reiser4, gli altri più o meno siamo lì...
Purtroppo però in un fileserver è altamente sconsigliato.
XFS ha giustamente la fama di essere un file system ad alte prestazioni, ma molte delle sue potenzialità vanno abilitate e configurate a mano, come l'I/O real time
hai un link a della documentazione per settare questo XFS?
grazie :)
No, io dicevo una cosa un po diversa: quello che intendevo per esempio è che XFS fornisce delle API che permettono ai programmi scritti in modo apposito di riservarsi una quantità di banda garantita e di accedere direttamente al disco senza passare per la cache, una caratteristica unica di XFS e fondamentale per le applicazioni di editing video real time, oppure altri aspetti all'avanguardia, ma che danno il meglio su sistemi di fascia alta con software scritti apposta per usarli.
Che XFS è ad alte prestazioni va inteso in quel senso, per il general purpose dove queste cose non si usano tanto vale affidarsi al classico Ext3.
Se ti interessa comunque puoi guardare sul sito della SGI, ad esempio datasheet di XFS: http://oss.sgi.com/projects/xfs/datasheet.pdf
mcardini
19-11-2007, 12:09
Xfs e' adatto a trattare file di grosse dimensioni e se usi prevalentemente quelli, xfs e' consigliato.
Io di solito imposto tutto su ext3 e non mi hai tradito una volta, ma su file di grosse dimensioni e' un po' in difficolta'.
Questo driver può leggere Ext, XFS e Reiser da windows http://www.crossmeta.com/crossmeta.html.
XFS non ha nessun problema di stabilità in se, solamente il fatto di tenere parecchio i dati in cache prima di scriverli lo rende più sensibile di altri agli arresti improvvisi del sistema.
XFS ha giustamente la fama di essere un file system ad alte prestazioni, ma molte delle sue potenzialità vanno abilitate e configurate a mano, come l'I/O real time, perche possa essere sfruttato al massimo e si senta la differenza. Se uno non sa fare il tuning tanto vale che usi l'Ext3.
Hai qualche guida buona per il tuning di XFS?
non ho guide o howto, come ho detto nel post #10, quello che rende XFS allettante sono alcune caratteristiche avanzate che per essere sfruttate richiedono che anche il resto dell'ambiente sia progettato apposta, per tuning non intendevo dire che bisogna leggere un howto e modificare un file di configurazione per aumentare le prestazioni! :p
Mi riferivo a questo per esempio:
"Il server SGI Altix 3000, che frantumò il record del benchmark per l'High Performance Computing dei supercomputer nel 2003, utilizzava kernel Linux, processori Intel Itanium e XFS come file system." :cool:
Per l'uso generico, salvo casi particolari, le prestazioni sono comunque limitate dall'hardware sottostante per cui la scelta del filesystem per quanto riguarda le prestazioni conta in percentuale esigua.
Comunque è vero, per i file di grandi dimensioni XFS sulla carta (e anche in pratica) è il migliore, se hai un server stabile puoi usare quello. :)
non ho guide o howto, come ho detto nel post #10, quello che rende XFS allettante sono alcune caratteristiche avanzate che per essere sfruttate richiedono che anche il resto dell'ambiente sia progettato apposta, per tuning non intendevo dire che bisogna leggere un howto e modificare un file di configurazione per aumentare le prestazioni! :p
Mi riferivo a questo per esempio:
"Il server SGI Altix 3000, che frantumò il record del benchmark per l'High Performance Computing dei supercomputer nel 2003, utilizzava kernel Linux, processori Intel Itanium e XFS come file system." :cool:
Per l'uso generico, salvo casi particolari, le prestazioni sono comunque limitate dall'hardware sottostante per cui la scelta del filesystem per quanto riguarda le prestazioni conta in percentuale esigua.
Comunque è vero, per i file di grandi dimensioni XFS sulla carta (e anche in pratica) è il migliore, se hai un server stabile puoi usare quello. :)
Capito, grazie. :)
XFS non ha nessun problema di stabilità in se, solamente il fatto di tenere parecchio i dati in cache prima di scriverli lo rende più sensibile di altri agli arresti improvvisi del sistema.
raramente mi capita di dover resettare il PC :(
se lo faccio con EXT3 o REISER al boot successivo tutto OK, l'unica volta che ho resettato un XFS il filesystem si è disintegrato :muro:
tempo fa ho letto che è possibile limitare questo fenomeno aggiungendo dei parametri nel file /etc/fstab ma non riesco a trovare cosa aggiungere...
raramente mi capita di dover resettare il PC :(
se lo faccio con EXT3 o REISER al boot successivo tutto OK, l'unica volta che ho resettato un XFS il filesystem si è disintegrato :muro:
tempo fa ho letto che è possibile limitare questo fenomeno aggiungendo dei parametri nel file /etc/fstab ma non riesco a trovare cosa aggiungere...
In effetti quello è uno degli svantaggi, per cui va usato su macchine affidabili e in caso di freeze prima di resettare c'è una combinazione di tasti da premere (magic sysrq key) che fa il flush dei dati.
Il parametro a cui ti riferisci probabilmente sono le write barrier, che però in questo caso non servono perchè XFS usa la delayed allocation indipendentemente da esse.
Per rendere sicuro in quel senso XFS bisogna attivare le write barrier e disattivare l'uso della cache di XFS, pero così si perde una delle caratteristiche migliori di questo fs.
Il parametro a cui ti riferisci probabilmente sono le write barrier, che però in questo caso non servono perchè XFS usa la delayed allocation indipendentemente da esse.
Per rendere sicuro in quel senso XFS bisogna attivare le write barrier e disattivare l'uso della cache di XFS, pero così si perde una delle caratteristiche migliori di questo fs.
esatto, intendevo proprio le write barrier :)
che cosa fa esattamente questa opzione e come si abilita?
riassumendo:
che filesystem conviene usare?
per quanto riguarda robustezza ed affidabilità EXT3 è la scelta migliore?
tratto dalle parole di uno sviluppatore SGI:
"XFS is only safe when you have:
a) no write caching on the drive (barrier or nobarrier)
b) non-volatile write caching on the drive (barrier or nobarrier)
c) volatile write caching and barriers supported and enabled
The same conditions hold true for any filesystem that requires I/O ordering
guarantees to maintain filesystem consistency."
Se hai una buona macchina con un OS stabile e non ci sono problemi di alimentazione allora XFS è a prova di bomba, altrimenti se vuoi stare più sicuro puoi usare Ext3.
Comunque io ho resettato più volte il mio PC con partizioni xfs e non ho perso nessun dato... la quantità di dati che vengono persi dipende dal momento in resetti, a volte può anche non succedere niente.
In effetti quello è uno degli svantaggi, per cui va usato su macchine affidabili e in caso di freeze prima di resettare c'è una combinazione di tasti da premere (magic sysrq key) che fa il flush dei dati.
Il parametro a cui ti riferisci probabilmente sono le write barrier, che però in questo caso non servono perchè XFS usa la delayed allocation indipendentemente da esse.
Per rendere sicuro in quel senso XFS bisogna attivare le write barrier e disattivare l'uso della cache di XFS, pero così si perde una delle caratteristiche migliori di questo fs.
per magic sysrq key intendi la combinazione di tasti :
alt+Rsist+R
alt+Rsist+E
alt+Rsist+I
alt+Rsist+S
alt+Rsist+U
alt+Rsist+B
?
Perchè a volte capita di avere freeze del server x, ma il kernel a basso livello non si è mai bloccato e con questa combinazione di tasti son sempre riuscito a riavviare la macchina.
per magic sysrq key intendi la combinazione di tasti :
alt+Rsist+R
alt+Rsist+E
alt+Rsist+I
alt+Rsist+S
alt+Rsist+U
alt+Rsist+B
?
Perchè a volte capita di avere freeze del server x, ma il kernel a basso livello non si è mai bloccato e con questa combinazione di tasti son sempre riuscito a riavviare la macchina.
Questa intendevo:
alt+rsist+S: Sync all mounted filesystems
XFS così dovrebbe fare il flush dei dati che non ha ancora inviato all'harddisk e poi resettando non dovrebbero esserci perdite di dati (non lo so per certo, è un'ipotesi...)
tratto dalle parole di uno sviluppatore SGI:
"XFS is only safe when you have:
a) no write caching on the drive (barrier or nobarrier)
b) non-volatile write caching on the drive (barrier or nobarrier)
c) volatile write caching and barriers supported and enabled
The same conditions hold true for any filesystem that requires I/O ordering
guarantees to maintain filesystem consistency."
non mi è molto chiaro ma prendendo spunto da questi link:
https://forums.gentoo.org/viewtopic-t-486640-highlight-write+cache.html
http://wiki.gentoo-italia.net/index.php/XFS_Filesystem:_come_migliorare_le_performance
sembra che fstab andrebbe settato come segue:
/dev/xxx /mount_point xfs noatime,nodiratime,barrier 0 0
non mi sono chiare le seguenti cose:
1) l'opzione "barrier" va indicata anche con kernel >2.6.17 :confused:
2) cosa fanno le opzioni "noatime,nodiratime"
3) logbufs=X e logbsize=X servono realmente? se si, come settarle?
grazie ;)
Mah, non sono sicuro che quell'articolo sia del tutto esatto, in quanto da la colpa delle perdita dei dati di XFS esclusivamente alla write cache dell'harddisk, quando invece è la delayed allocation la causa principale, poichè i dati vengono cachati in memoria centale anche per un lungo periodo prima di essere scritti.
Il fatto che si verifichi un arresto improvviso nel momento in cui l'hard disk non ha ancora svuotato la write cache può causare perdite su tutti i file system, non solo su xfs, e comunque si tratta al massimo di pochi megabyte.
Le write barrier dovrebbero essere abilitate di default dal 2.6.18, per cui non serve specificarlo a parte, mentre noatime semplicemente evita di scrivere la data e l'ora dell'ultimo accesso su ogni file, cambia poco...
Questa intendevo:
alt+rsist+S: Sync all mounted filesystems
XFS così dovrebbe fare il flush dei dati che non ha ancora inviato all'harddisk e poi resettando non dovrebbero esserci perdite di dati (non lo so per certo, è un'ipotesi...)
Infatti nella sequenza per il riavvio sicuro del pc è presente la combinazione di tasti alt + Rsist + S ;)
ed è proprio in quel punto che noto la lucina rossa degli hd accendersi per mezzo secondo :)
darkbasic
19-11-2007, 22:22
Le perdite di dati erano dovute ad hard disk di scarsa qualità che comunicavano al SO di aver scritto correttamente i dati quando in realtà erano ancora in cache. Il problema si aggirava parzialmente disabilitando le write barriers.
Con un kernel recente, un buon hard disk e le write barriers attive non ci sono problemi con xfs.
Un disco cosi sarebbe da regalarlo al proprio peggior nemico :tie:
Sicuramente era un problema, ma oltre alla cache dell'harddisk XFS è sensibile lo stesso agli arresti improvvisi a causa di questa caratteristica:
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.
Come si evince XFS mantiene i dati in memoria centrale il più a lungo possibile prima di scriverli, per cui nel momento in cui la macchina si arresta questi dati vanno comunque persi, indipendentemente dalla cache dell'hard disk. D'altra parte è stato progettato per sistemi di fascia alta che naturalmente non hanno problemi di alimentazione.
I vantaggi di questa tecnica sono notevoli sulle prestazioni e sulla frammentazione, ad esempio c'è un'altissima probabilità che i file temporanei che vengono creati e cancellati poco dopo vivano solamente in RAM senza far lavorare il disco fisso.
Io lo uso lo stesso con tranquillità sul desktop, visto che accendo il PC alla mattina e lo spengo alla sera e per l'uso che ne faccio è costretto a scrivere i dati frequentemente, per cui quelle volte che mi è saltata la corrente non ho perso niente, pero in alcuni casi XFS puo decidere di ritardare la scrittura dei dati anche di parecchio tempo (si parla di ore).
Rsist sarebbe lo stamp giusto?
darkbasic
20-11-2007, 13:45
Ovvio ali problemi derivanti da un pesante utilizzo della cache non si può ovviare (a meno di controller con batteria tampone) e comunque non è un grosso problema a mio avviso, ma la maggior parte delle lamentele che si sentivano in passato erano dovute proprio ad hard disk farlocchi :D
La possibilità di perdere dati a causa della cache è altrimenti molto bassa (jfs è molto peggio sotto questo punto di vista)
manowar84
20-11-2007, 14:13
JFS ??
sconsigliato per server, io cmq lo uso sul pc fisso da aprile :D
E per quanto riguarda un fileserver con files di sopratutto di piccola dimensione (il 90% sarebbe mediamente sotto i 10MB) ?
Ho provato a leggere un pò in giro e come al solito ci sono pareri discordanti..
darkbasic
21-11-2007, 16:32
xfs o ext3
reiserfs per file molto piccoli (10 MB non è molto piccoli). praticamente i vantaggi si fanno notare se compili molto software (centinaia di migliaia di file piccolissimi).
darkbasic
21-11-2007, 16:35
sconsigliato per server, io cmq lo uso sul pc fisso da aprile :D
Dai test che ho fatto jfs risulta essere mediamente più lento persino di ext3.
xfs o ext3
reiserfs per file molto piccoli (10 MB non è molto piccoli). praticamente i vantaggi si fanno notare se compili molto software (centinaia di migliaia di file piccolissimi).
Capisco..Considera che non compilerei granchè.
Una volta che il sistema è pronto diventerebbe un'unità di backup, quindi..
A questo punto potrei pensare di montare la root in reiser4 e la home in xfs o ext3..Come siamo messi a consumo di CPU per questi ultimi 2? (non ho un processore molto potente..).
Grazie :)
darkbasic
21-11-2007, 16:39
A questo punto potrei pensare di montare la root in reiser4
Io non ho mai avuto problemi, ma non posso garantirti che non ne avrai. Reiser4 è software sperimentale e probabilmente lo rimarrà per sempre.
Per quanto riguarda l'uso della cpu, reiser4 è quello che ne fa maggiormente uso, ma a meno che la cpu non sia proprio un cancro non è un parametro da valutare. Il filesystem meno esoso a livello di cpu è jfs, ma non ha senso farsi condizionare da questo parametro a meno che tu non abbia un pentium I
Dcromato
21-11-2007, 16:41
Io ho reiser su /
jfs su /home che in un certo senso è simile a ext3 ma è molto piu leggero.
Io non ho mai avuto problemi, ma non posso garantirti che non ne avrai. Reiser4 è software sperimentale e probabilmente lo rimarrà per sempre.
Per quanto riguarda l'uso della cpu, reiser4 è quello che ne fa maggiormente uso, ma a meno che la cpu non sia proprio un cancro non è un parametro da valutare. Il filesystem meno esoso a livello di cpu è jfs, ma non ha senso farsi condizionare da questo parametro a meno che tu non abbia un pentium I
Ti ringrazio per la panoramica..valuterò allora il reiser per la /.
Ho un pentiumIII 600mhz, che comunque è abbastanza più prestante di un pentiumI spero :sofico:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.