# [TIP] migliorare le performance di SGI XFS Filesystem

## !equilibrium

/EDIT: con xfsprogs-2.9 e le recenti versioni del kernel linux (2.6.23+) i miei tips non sono più necessari perchè sono diventati il default (ciò dimostra che le mie argomentazioni erano valide) in fase di formattazione. L'unica feature che è cambiata è l'agcount, che a seguito di una modifica del driver XFS nei recenti kernel linux, è un valore fisso e si adegua in modo ottimale in base alla dimensione della partizione. Infine consiglio caldamente l'attivazione del lazy-count di XFS come unico "tip" in quanto non è ancora il default, ed aggiunge un sostanziale aumento di performance in scrittura.

MITI E LEGGENDE RIGUARDANTI XFS:

[-] XFS è veloce a leggere/scrivere file di grosse dimensioni ma non è idoneo a gestire file di piccole dimensioni.

Falso, dal kernel 2.6.20+ il filesystem XFS scala in modo lineare sia per file di piccole dimensioni che file di grosse dimensioni (leggi: è veloce a leggere/scrivere file di dimensioni piccole ne più ne meno come quando legge i file di dimensioni grosse).

[-] XFS perde i dati e si corrompe facilmente tant'è che la stessa SGI raccomanda l'uso di un UPS con il suo filesystem.

Falso, nelle FAQ della SGI (e anche qui) è spiegato bene che XFS, come tutti i filesystem in generale, soffre di perdite di dati nel caso in cui avviene una brusca interruzione dell'alimentazione elettrica con la feature Write Cache hardware degli hard disk PATA/SATA abilitata. Senza un adeguato sistema di UPS la Write Cache dell'HD viene azzerata prima che i dati siano stati realmente scritti sul dispositivo, generando la perdita di dati e/o la corruzione del filesystem XFS. Questo problema non è un bug di XFS e riguarda *qualunque* filesystem, così come non esistono filesystem che reagiscono meglio in caso di shutdown forzato del pc o che sono esenti per natura dal suddetto problema (chi sostiene questi principi poco o nulla sa sui filesystem e sta palesemente mentendo al solo scopo di proporre un determinato filesystem come migliore degli altri). Di default gli HDs hanno la Write Cache abilitata, basta disattivarla per non incappare nel problema (sui dischi PATA ciò determina una evidente perdita di performance dovuta ai limiti dello standard PATA).

[-] OSYNCISDSYNC migliora le performance di XFS

Falso. A discapito di quanti sostengono che il montaggio di partizioni XFS con l'opzione osyncisdsync garantisca performance maggiori, l'effetto che si ottiene e' esattamente uguale a quello standard. Va fatta una premessa pero', l'opzione osyncisdsync serve solo per permettere le operazioni di scrittura di tipo O_SYNC (osyncisdsync = scritture sincrone tramite direct I/O, il default di XFS sono le scritture asincrone, async), senza, il filesystem li tradurrebbe in chiamate asincrone. Il miglioramento di 'performance' e' rilevabile solo e soltanto a livello di applicazione se questa e' in grado di sfruttare appieno O_SYNC (direct I/O), ma non ci sara' mai un miglioramento 'generale' a livello di scrittura/lettura. Allo stato attuale delle cose, non esistono nel mondo opensource molte applicazioni che fanno uso in modo nativo di direct I/O (so di sendmail e basta, se qualcuno ne conosce altri me lo faccio sapere), lo e' invece nel caso di IBM AIX dove tutto il sistema operativo e le varie applicazioni, compreso il filesystem (JFS) sfruttano appieno O_SYNC tramite direct I/O. Dal kernel 2.6.20 tale opzione e' abilata di default e ne viene deprecat l'uso via mount

letture correlate a O_SYNC per chi ne vuole sapere di piu':

- IBM AIX

- Daniel Robbins - Advanced Filesystem Implementor-s guide

Strumenti utili di benchmarsk:

Bonnie originale di Tim Bray

Bonnie di Kurt Garloff

Bonnie++ di Russell Coker

IOzone (raccomandato)

Documentazione utile

SGI - Official XFS Filesystem Structure

----------

## !equilibrium

p.s.: questo è solo un primo anticipo, poi aggiungerò altri tweak, li sto testando e quando avrò dei dati concreti aggiornerò questo thread  :Wink: 

----------

## Cazzantonio

Una cosa... come si aumenta la stabilità di xfs rispetto ai reboot?

Io ho sperimentato perdite di dati ingenti (beh, non ingenti in quantità ma in qualità... in pratica tutti i file aperti al momento del reset) in caso di kernel panick (dovuto agli ati-drivers) e di conseguente reset.

Non è molto sicuro usare xfs mi pare...

[MOD]L'ho aggiunto alla sezione TIPS e lo sposto nel subforum Off Topic[/MOD]

----------

## !equilibrium

 *Cazzantonio wrote:*   

> Una cosa... come si aumenta la stabilitï¿½ di xfs rispetto ai reboot?

 

in questo caso c'Ã¨ poco da fare, fin quando non migliorano XFS per linux (su SGI questi problemi non esistono) il difetto resta... poi Ã¨ anche ovvio che se usi software/driver non stabili, non Ã¨ colpa di xfs se la macchina si riavvia o va in kernel panic...

 *Quote:*   

> Non ï¿½ molto sicuro usare xfs mi pare... 

 

non direi proprio, va usato con le giuste precauzioni, cioÃ¨ con un sistema stabile e con gruppo di continuitÃ ; nella mia societÃ  si usano solo ed esclusivamente XFS sui server di produzione e da 3 anni a questa parte non ho perso nemmeno 1 bit (cosa che invece non posso dire con ext3 e reiserFS); poi ci sono i soliti discorsi che danno vita ai flames, per tanto mi fermo qua perchÃ¨ li voglio evitare   :Wink: 

 *Cazzantonio wrote:*   

> [MOD]L'ho aggiunto alla sezione TIPS e lo sposto nel subforum Off Topic[/MOD]

 

Ã¨ un argomento off-topic?   :Sad: 

----------

## Cazzantonio

 *DarkAngel76 wrote:*   

> Ã¨ un argomento off-topic?  

 

Beh... non c'entra direttamente con gentoo (ma con linux in generale)...

Comunque mica è un'offesa sai   :Very Happy: 

Bisogna trovare il modo per far capire agli utenti che il forum OT non è il forum del trash   :Rolling Eyes:   :Wink: 

----------

## !equilibrium

ho aggiunto i punti (5) e (6), utili per chi ha server di produzione e RAID (sia hardware che software)

----------

## !equilibrium

 *Cazzantonio wrote:*   

> Beh... non c'entra direttamente con gentoo (ma con linux in generale)...
> 
> Comunque mica ï¿½ un'offesa sai   

 

no assolutamente, non mi sono offeso, solo non capisco...

fino a qualche tempo fa l'OT era tutto quello che non riguardava gentoo/linux... se avete cambiato la netiquette allora Ã¨ soltanto un mio difetto oppure non ho mai capito il vero senso dell' OT. Anche perchÃ¨ ho scritto altri TIPS tempo fa e in nessuno ho dovuto mettere il tag OT, e cosi Ã¨ per altri TIPS/HOWTO presenti nel forum italiano...

 *Cazzantonio wrote:*   

> Bisogna trovare il modo per far capire agli utenti che il forum OT non ï¿½ il forum del trash   

 

bhe il problema forse sta proprio nel nome del forum non credi? OT non Ã¨ proprio molto indicato come definizione, il 90% degli utenti penserÃ  sicuramente che li dentro si trovano thread che riguardano tutto e di piÃ¹ ma non legati al mondo linux in generale  :Very Happy:  (tipo gli sfoghi sui disservizi adsl, segnalazioni di spam e cose cosi, si insomma ci siamo capiti)

poi sinceramente non saprei, probabile che sbaglio io ad interpretare le cose, ergo, vado a darmi una rilettura della netiquette che Ã¨ meglio.

----------

## fedeliallalinea

 *DarkAngel76 wrote:*   

> fino a qualche tempo fa l'OT era tutto quello che non riguardava gentoo/linux... se avete cambiato la netiquette allora Ã¨ soltanto un mio difetto oppure non ho mai capito il vero senso dell' OT. Anche perchÃ¨ ho scritto altri TIPS tempo fa e in nessuno ho dovuto mettere il tag OT, e cosi Ã¨ per altri TIPS/HOWTO presenti nel forum italiano..

 

Il problema che non c'e' ancora una buona separazione, magari dovremmo aggiungere qualche subforums. Comunque il forum italian deve rimanere solo allo scopo di aiutare la gente che ha problemi strettamente inerenti a gentoo.

----------

## !equilibrium

 *fedeliallalinea wrote:*   

> Il problema che non c'e' ancora una buona separazione, magari dovremmo aggiungere qualche subforums. Comunque il forum italian deve rimanere solo allo scopo di aiutare la gente che ha problemi strettamente inerenti a gentoo.

 

ah ecco, allora messa cosi la cosa mi suona decisamente meglio e il tutto ha un senso... e trova anche senso l'affermazione di Cazzantonio.

si, decisamente ci vuole un'altro subforums per la documentazione/howto/tips.

grazie della puntualizzazione fedeliallalinea.

----------

## .:deadhead:.

Evviva evviva son tornati gli hackers! Mi mancavano questi tips tecnici a-la-Fonderia: li adoro! Per DarkAngel Hip Hip Hurra!!!!!!

----------

## GNU/Duncan

Ottimo, è un po' che cercavo qualcosa che riassumesse un po' di info per il FS XFS  :Smile: 

----------

## !equilibrium

ho fatto una modifica alla sezione [4] per spremere il massimo dal FS. utilissima soprattutto sui notebook (mi ha allungo di circa 15 minuti la durata della batteria)

 *GNU/Duncan wrote:*   

> Ottimo, ï¿½ un po' che cercavo qualcosa che riassumesse un po' di info per il FS XFS 

 

mi fa piacere che i miei tips servano a qualcosa  :Smile: 

 *.:deadhead:. wrote:*   

> Evviva evviva son tornati gli hackers! Mi mancavano questi tips tecnici a-la-Fonderia: li adoro! Per DarkAngel Hip Hip Hurra!!!!!!

 

grazie!   :Embarassed: 

----------

## Cazzantonio

resta il problema che se ti dimentichi il portatile, finisce la batteria e ti si spenge di botto il pc non hai idea se al prossimo riavvio i dati ci saranno tutti... oppure se hai un kernel panick o un freeze qualsiasi...

Mi spiegate voi come fate? Io XFS lo metterei volentieri ma questo problema mi sembra un po' troppo grave per soprassedere... Se voi lo usate significa che avete trovato il modo di ovviare a questa cosa no?

----------

## !equilibrium

 *Cazzantonio wrote:*   

> resta il problema che se ti dimentichi il portatile, finisce la batteria e ti si spenge di botto il pc non hai idea se al prossimo riavvio i dati ci saranno tutti... oppure se hai un kernel panick o un freeze qualsiasi...
> 
> Mi spiegate voi come fate? Io XFS lo metterei volentieri ma questo problema mi sembra un po' troppo grave per soprassedere... Se voi lo usate significa che avete trovato il modo di ovviare a questa cosa no?

 

a parte che:

a- ci sono gli script per monitorare la batteria e far fare lo spegnimento al notebook quando sta in riserva  :Wink: 

b- se si spegne di botto il pc con XFS, il danno massimo che hai Ã¨ perdere i files non ancora scritti, non hai corruzione sulla partizione (cosa che invece con gli altri FS, soprattutto reiserFS succede spesso anche senza bisogno di uno shutdown forzato)

c- se ti si spegne di botto il pc, o va in kernel panic, qualunque FS non regge bene ugualmente, attualmente solo ext3 e XFS reggono bene(leggi 'senza ripercussioni') le cadute, ext3 dopo continui freeze si pianta e si corrompe, mentre XFS no perchÃ¨ ha un sistema di protezione suo interno che in caso di problemi blocca qualunque accesso in scrittura per prevenire danni.

d- i kernel panic sono rarissimi, Ã¨ da parecchio che non me ne capita uno, per cui non vedo la preoccupazione; se capita in fase di boot le partizioni manco vengono toccate, se invece succede in fase di init, bhe c'Ã¨ quasi al 99% un problema hardware e questo non Ã¨ colpa degli sviluppatori di XFS o di qualsiasi altro FS.

per cui non capisco tutta questa preoccupazione; praticamente mi state dicendo che preferite usare reiserfs4 perchÃ¨ i dati in memoria te li salva ugualmente anche in caso di freeze (fa nulla se poi al riavvio tutta la partizione Ã¨ sbragata), mentre Ã¨ un'atrocitÃ  se XFS ti salva l'integritÃ  della partizione a discapito perÃ² della perdita di 1 o 2 files (che fin ad ora mi Ã¨ capitato solo sul file /etc/fstab un paio di volte perchÃ¨ hald se lo tiene sempre in memoria)? Ã¨ dunque questa la preoccupazione?

 *Quote:*   

> non hai idea se al prossimo riavvio i dati ci saranno tutti.

 

scusa cazzantonio, ma questa informazione da dove l'hai reperita? intendo documentazione ufficiale, perchÃ¨ non mi risulta da nessuna parte (soprattutto visto che XFS Ã¨ un FS sviluppato da oltre 15 anni da SGI per ambienti e situazioni altamente critiche), tutto quello che puoi perdere, se perdi qualcosa, sono i files rimasti aperti in memoria, non vedo perchÃ¨ ti dovrebbero sparire dati a random...

----------

## Cazzantonio

hai ragione scusa... non intendevo lanciare un flame anzi... volevo proprio sapere quello che mi hai detto perché ho intenzione di mettere xfs sulla root del portatile.

Io mi sono trovato molto bene con xfs... lo usavo sulla  partizione delle home solo che, in seguito ad alcuni kernel panick causati dai driver ati (se non fosse per loro non avrei mai sperimentato un kernel panick) mi sono spariti diversi file... come ad esempio i bookmark se avevo firefox aperto etc...

Il fatto è che mi pare di aver capito che xfs deve essere usato con cognizione di causa... che accade ad esempio (non lo so... chiedo) col p2p? se un programma sta scrivendo un file bello grosso (e ne avrà per parecchio) e poi il disco viene spento improvvisamente il file sparisce?

Io ho avuto esperienze di corruzione di fs in reiserfs (da cui per pura fortuna ho ritrovato tutto), con xfs (dove l'fs rimaneva stabile, solo perdevi qualche file qua è la'... vedi l'episodio dei bookmark) e mai con ext3 per cui mi ero convinto che l'unico fs sicuro fosse quest'ultimo.

In pratica quello che mi dici è che con xfs rischio solo di perdere i file aperti in quel momento. Bene. Ma se lo uso su una partizione di root qual'è il rischio? Non ho idea di quali e quanti file siano aperti contemporaneamente e a rischio perdita... inoltre con un portatile il rischio è ovviamente più alto che con un fisso (affidare la stabilità di un sistema ad uno script che spenge il pc è azzardato... se hai un gruppo di continuità il discorso è ben diverso...)

Se mi dici che rischio solo fstab nel caso usi hal (e non lo uso) allora vado tranquillo e migro la mia root su xfs, altrimenti devo un po' capire a cosa vado incontro

----------

## !equilibrium

 *Cazzantonio wrote:*   

> Il fatto ï¿½ che mi pare di aver capito che xfs deve essere usato con cognizione di causa... che accade ad esempio (non lo so... chiedo) col p2p? se un programma sta scrivendo un file bello grosso (e ne avrï¿½ per parecchio) e poi il disco viene spento improvvisamente il file sparisce?

 

no no, non preoccuparti, perdi solo il pezzo di file che Ã¨ in memoria, poi dipende, se tutto il file Ã¨ in memoria ed Ã¨ in atto una lettura/scrittura lo perdi tutto (o meglio, non perdi il file in se, perdi il suo contenuto, te lo ritrovi vuoto), ma se Ã¨ solo in memoria per motivi suoi perdi solo i KB di differenza tra quelli presenti in memoria rispetto a quelli presenti nel file (il quale resta sano e salvo); con il p2p non hai problemi, perchÃ¨ nessun p2p si tiene 1Gb di file in download in memoria, ma si scarica tronconi di Kb alla volta e poi ricostruisce l'intero file pezzetto per pezzetto, male che capita perdi l'ultimo troncone di KB scaricato. insomma, mai perso misteriosamente nessun file grosso per un improvviso shutdown al 99,9% del download  :Wink: 

 *Cazzantonio wrote:*   

> Io ho avuto esperienze di corruzione di fs in reiserfs (da cui per pura fortuna ho ritrovato tutto), con xfs (dove l'fs rimaneva stabile, solo perdevi qualche file qua ï¿½ la'... vedi l'episodio dei bookmark) e mai con ext3 per cui mi ero convinto che l'unico fs sicuro fosse quest'ultimo.

 

vabbhe su reiserfs si sa... ma ext3 resta comunque un ottimo FS e molto affidabile, solo che XFS ha delle features che ext3 non ha ancora; per esempio l'utilizzo di ext3 su RAID molto complessi non Ã¨ fattibile, o addirittura laddove le performance sono 'vitali' (esempio tipico, cluster di RAID per lo streaming) si ottiene l'esatto opposto del termine 'performance', anche i limiti di capacitÃ  massima sono diversi perchÃ¨ XFS permette capacitÃ  massime molto superiori. Tutto questo ovviamente non si ripercuote su un normale pc, dove XFS e ext3 stanno praticamente a parimerito, c'Ã¨ solo qualche piccola differenza e sta all'utente finale decidere quale dei 2 scegliere; se l'utente deve fare molti lavori multimediali (suono/grafica/animazione/3D) l'ideale Ã¨ indubbiamente XFS perchÃ¨ permette affidabilitÃ  e velocitÃ  su file molto grossi (con reiserfs4 te lo sogni di lavorare su immagini TIFF a 32bit da 250Mb l'una, o a realizzare 30 minuti di animazione 3D in alta risoluzione fatta con Blender... per esperienza ti posso assicurare che si inchioda tutto! il kernel proprio caccia fuori la manina dal monitor e stacca la spina per auto applicarsi l'eutanasia...), per tutti gli altri casi basta e avanza ext3

 *Cazzantonio wrote:*   

> In pratica quello che mi dici ï¿½ che con xfs rischio solo di perdere i file aperti in quel momento. Bene. Ma se lo uso su una partizione di root qual'ï¿½ il rischio? Non ho idea di quali e quanti file siano aperti contemporaneamente e a rischio perdita... inoltre con un portatile il rischio ï¿½ ovviamente piï¿½ alto che con un fisso (affidare la stabilitï¿½ di un sistema ad uno script che spenge il pc ï¿½ azzardato... se hai un gruppo di continuitï¿½ il discorso ï¿½ ben diverso...)
> 
> Se mi dici che rischio solo fstab nel caso usi hal (e non lo uso) allora vado tranquillo e migro la mia root su xfs, altrimenti devo un po' capire a cosa vado incontro

 

su una root puoi tranquillamente usare ext3, ma se hai un'unica partizione per tutto, root e home e vuoi usare XFS al massimo perdi qualche log in caso di shutdown forzato, altri file che restano in memoria spesso, non ce ne sono e/o comunque non me ne sovviene in questo momento oltre ai giÃ  citati. se hai due partizioni separate ricorda che XFS richiederÃ  il doppio di risorse rispetto ad una sola partizione, soprattutto se modifichi i valori di default come indicato nel mio howto (non Ã¨ che ti vanno via MB a pacchi, anzi, tutt'altro... ma se hai poca memoria e devi lavorare su file mediamente grossi, forse Ã¨ meglio preservare la root con ext3); tieni infine presente che XFS quando raggiunge la fine dello spazio diventa molto lento, per esempio mi Ã¨ capitato di spostare un file iso da 1.5Gb da una partizione con solo 10Mb liberi e ci ha impiegato quasi 1 ora contro i 5 minuti tradizionali, per cui valuta l'uso che fai del tuo pc, e delle situazioni in cui incorri quotidianamente.

Per il resto non so che dirti, io ho optato per XFS perchÃ¨ al di lÃ  degli shoutdown forzati, dei kernel panic o altre sfighe, qualora ci fosse un malfunzionamento hardware dell'hd o nel caso di software che si mette a scrivere fregnaccie, il FS Ã¨ in grado di auto freezarsi impedendo quindi ulteriori danneggiamenti e preservandomi i dati da morte certa (e questo, mi ha giÃ  salvato il culo in molte occasioni su server di produzione)

----------

## fedeliallalinea

Ma per il problema dei dati persi che si trovano in ram non e' sufficiente lanciare qualche volta un bel sync ogni tanto (o addirittura metterlo nella crontab)?

----------

## .:deadhead:.

Questo credo che ti possa servire cazzantonio  :Very Happy:  Era tra i tips ufficiali

https://forums.gentoo.org/viewtopic.php?t=178164

Complimenti ancora a DarkAngel: quel nodiratime manco c'è nel man di mount... Azz questo ci insegna che non di solo mount vive il sysadmin... Ma vale anche per altri FS o è prerogativa di xfs?

----------

## Cazzantonio

 *.:deadhead:. wrote:*   

> Questo credo che ti possa servire cazzantonio  Era tra i tips ufficiali
> 
> https://forums.gentoo.org/viewtopic.php?t=178164

 

Yes I kown   :Wink: 

ma

 *Cazzantonio wrote:*   

> affidare la stabilità di un sistema ad uno script che spenge il pc è azzardato

 

ovviamente IMHO

----------

## !equilibrium

 *.:deadhead:. wrote:*   

> Complimenti ancora a DarkAngel: quel nodiratime manco c'ï¿½ nel man di mount... Azz questo ci insegna che non di solo mount vive il sysadmin... Ma vale anche per altri FS o ï¿½ prerogativa di xfs?

 

grazie!, si nodiratime Ã¨ una prerogativa di tutti i FS, fa parte del mount, l'ho scoperto tempo fa cercando di capire come far funzionare bene CIFS nell'fstab e fui costretto ad aprire i sorgenti di mount e sbirciarmi tutto il codice... fu cosi che per caso incappai in nodiratime, il resto l'ha fatto tutto la curiositÃ   :Wink: 

----------

## Cazzantonio

A proposito della deframmentazione come ci si deve comportare? Come e quanto spesso va eseguita?

Non ho mai eseguito deframmentazione su un sistema linux e mi chiedo come funzioni questa cosa? Anche gli altri filesystem soffrono la frammentazione?

----------

## !equilibrium

 *Cazzantonio wrote:*   

> A proposito della deframmentazione come ci si deve comportare? Come e quanto spesso va eseguita?
> 
> Non ho mai eseguito deframmentazione su un sistema linux e mi chiedo come funzioni questa cosa? Anche gli altri filesystem soffrono la frammentazione?

 

dipende molto dal FS e dal modo in cui scrivono i dati, come spiegai sopra, se un file viene scritto in modalitÃ  Round Robin Ã¨ molto probabile che venga deframmentato; su un desktop la deframmentazione Ã¨ davvero minimale, Ã¨ molto + probabile su un fileservers; comunque ti basta lanciare l'utiliy di deframmentazione di XFS con l'opzione 'verbose' per vedere se trova qualcosa di fuori posto o da ottimizzare.

----------

## Luca89

Per quanto ne so, su linux, l'unico filesystem che subisce la frammentazione è ext2, tutti gli altri dovrebbero andare tranquilli.

----------

## !equilibrium

 *Luca89 wrote:*   

> Per quanto ne so, su linux, l'unico filesystem che subisce la frammentazione ï¿½ ext2, tutti gli altri dovrebbero andare tranquilli.

 

non Ã¨ proprio corretto, tutti i FS subiscono l'effetto della deframmentazione, solo che alcuni implementano al loro interno routine per evitarla il + possibile o eseguono cicli periodici di deframmentazione runtime; ext2 e ext3 lo fanno per esempio, solo che la routine di ext2 non Ã¨ molto efficiente, mente quella di ext3 riduce quasi al nulla la deframmentazione generale (ecco perchÃ¨ per ext2 esistono tools di deframmentazione mente per ext3 no). Attenzione perÃ², quanto detto vale per un ambiente single-user e/o con un OS single-tasking, la cosa diventa diversa in un ambiente multi-user e/o multi-tasking (esempio tipico il fileserver) perchÃ¨ il FS non ha il 'tempo materiale' per eseguire sempre le sue routine interne di archiviazione/ottimizzazione. ReiserFS mi pare non abbia proprio questa routine, e che ci sia un tool a pagamento per reiserFS4. XFS non fa nessuna ottimizzazione interna perchÃ¨ non ne ha bisogno (qui il discorso Ã¨ lungo e non mi va di entrare nel dettaglio) ma in ambienti multi-user subisce anche lui la deframmentazione, soprattutto quando lo spazio sull'hd si sta per esaure, per questo Ã¨ stata creata l'utility xfs_fsr.

----------

## Cazzantonio

via mi sa che metterò xfs sulla root... backuppo e via   :Wink: 

Per le home aspetterò di vedere come va con la root.... per ora rimango con ext3   :Razz: 

[EDIT]Pensavo..... per risolvere il prolema (possibile) degli shutdown improvvisi non potrebbe essere utile ridurre il numero e la grandezza dei buffers?

Ridurli ridurrebbe la latenza delle informazioni nella ram anche se peggiorerebbe la resa del filesystem....[/EDIT]

----------

## Cazzantonio

Prima la root era in reiserfs 3.6 e occupava 3.9 giga

ora in xfs ne occupa 4.6...

E' leggermente meno efficiente come capacità di storaggio dati ma non si notano cali apprezzabili di velocità...

In compenso ora spero di consumare meno batteria in carico pcu dovuto al filesystem   :Wink: 

----------

## Ic3M4n

@cazzantonio: io onestamente della quantità di hd occupato ho sempre avuto forti dubbi. soprattutto sulla bontà di reiser sotto questo aspetto. ho provato una volta a formattare una penna usb da 128Mb con reiser e mi diceva che lo spazio libero era di 68M o qualcosa del genere. con xfs invece di 110M (sempre più o meno). onestamente non me la so spiegare, però se anche su xfs un file dovesse occupare di più la dimensione totale della penna in M è maggiore. boh... illuminatemi.

----------

## Luca89

Ho notato anche io ciò detto da Ic3m4n, avevo una piccola partizione /boot in reiserfs e massimo vi entravano 2 kernel, dopo averla formattata in ext3 invece ne possono mettere molti di più. Secondo me reiserfs riserva troppo spazio per il journal.

----------

## Apetrini

Ho riposto la mia fiudcia in XFS, ma mi ha deluso...

L'ho usato per la root di tutto il sistema...

Poi ho fatto delle prove con dei moduli del kernel che freezavano il sistema, al 10-11 freeze dopo il riavvio molti file erano vuoti o pieni di schifezze...

MI si era corrotto

```
 

/etc/fstab

 /etc/mtab 

/etc/portage.keywords

/etc/portage.unmask

...

e molti altri...

 
```

Forse non è il filesystem piu adatto per la root del sistema...

Quando usavo reiser3.6 o anche reiser4 queste cose non succedevano. Magari dovevo perdere 40 minuti per correggere la partizione dopo ogni riavvio forzato, ma poi i miei dati gli avevo indietro tutti integri...

P.s. tutto questo era a patto che non si danneggiasse qualche settore del disco, questa cosa purtroppo reiser non la tollera e io per qualche cluster danneggiato perdevo giga di roba...

----------

## Ic3M4n

semplicemente in caso di crash i problemi li hai sui file aperti, che risulteranno corrotti al successivo riavvio. però è anche vero che non tutti ci mettiamo a smadonnare con i moduli del kernel come fai tu. io finora non ho mai avuto problemi, anzi... tra xfs e reiser non c'è paragone. io utilizzo xfs.

----------

## Cazzantonio

E' l'unica cosa davvero fastidiosa... per il resto è un ottimo filesystem.

Ora come ora ho la root in xfs e si vedrà.... su un fisso terrei reiser ma visto che ciuccia tanta cpu ed ho un portatile   :Rolling Eyes: 

Effettivamente il carico di xfs sulla cpu è davvero molto ridotto   :Wink: 

----------

## nick_spacca

 *Cazzantonio wrote:*   

> (...)
> 
> Ora come ora ho la root in xfs e si vedrà.... su un fisso terrei reiser ma visto che ciuccia tanta cpu ed ho un portatile  
> 
> (...)

 

Ah si...e come te ne accorgi????????? Io col portatile (meno potente del tuo...), senza fare nulla ho il proc che AL MASSIMO va a 3/5% di carico....e considerando tutte le cazzate/applet che ho attive (gkrellm &co.) non so quale sia il carico della cpu....raggiungo io max di utlizzo SOLO in compilazione...

(Secondo me reiser e' un ottimo filesystem che uso da + di 3 anni ormai, mi riservo di provare Xfs...)

----------

## Cazzantonio

 *nick_spacca wrote:*   

> Ah si...e come te ne accorgi????????? Io col portatile (meno potente del tuo...), senza fare nulla ho il proc che AL MASSIMO va a 3/5% di carico....e considerando tutte le cazzate/applet che ho attive (gkrellm &co.) non so quale sia il carico della cpu....raggiungo io max di utlizzo SOLO in compilazione...
> 
> (Secondo me reiser e' un ottimo filesystem che uso da + di 3 anni ormai, mi riservo di provare Xfs...)

 

A parte la potenza (0.16 ghz non mi sembrano questo scarto abissale) te ne acccorgi quando fai operazioni sui files, tipo lettura, scrittura etc...

Comunque ti ripeto... le differenze non sono poi abissali. Penso sostanzialmente che ogni fs abbia buone qualità, non esiste il miglior fs. Esistono fs adatti a quello che vuoi fare ed fs meno adatti.

Per esempio xfs ha tutta una serie di utilities che mi piaccioni molto...

----------

## nick_spacca

 *Cazzantonio wrote:*   

> A parte la potenza (0.16 ghz non mi sembrano questo scarto abissale) te ne acccorgi quando fai operazioni sui files, tipo lettura, scrittura etc...
> 
> Comunque ti ripeto... le differenze non sono poi abissali. Penso sostanzialmente che ogni fs abbia buone qualità, non esiste il miglior fs. Esistono fs adatti a quello che vuoi fare ed fs meno adatti.
> 
> Per esempio xfs ha tutta una serie di utilities che mi piaccioni molto...

 

Io penso che la migliore qualita' che possa avere un fs, sia quella di essere trasparente all'utente....nel senso che meno mi accorgo che c'e' meglio e'...

A questo punto pero' meglio smettere altrimenti si va OT di brutto   :Wink:  ...

----------

## .:deadhead:.

 *Apetrini wrote:*   

> Ho riposto la mia fiudcia in XFS, ma mi ha deluso...

 mi spiace per la perdita dei tuoi dati, ma il problema a monte non è che se risolvi il problema dei freeze magari non sottoponi ad eccessivo stress anche il tuo FS che così potrà lavorare in pace, sia essp xfs reiser o pokemonFS(r) ?

 *Apetrini wrote:*   

> tutto questo era a patto che non si danneggiasse qualche settore del disco, questa cosa purtroppo reiser non la tollera e io per qualche cluster danneggiato perdevo giga di roba...

   :Shocked:  Mi permetto di avanzare un dubbio: come hai provato a recuperare quei dati? Beninteso, mi spiace che ti sia capitato, ma io ho perso, causa badblock, cluster per circa 80k e dopo aver copiato tramite dd la partizione in questione ho lanciato il mio rebuild_tree . Risultato? nessun file perso. recupero al 100%. Era la mia / e non avevo grossi file sopra, ma credo che il test sia indicativo.

Inizio a pensare che una buona dose di ( | ) sia la miglior soluzione dopo un ups ed un kernel stabile   :Rolling Eyes:   :Laughing: 

----------

## Apetrini

 *.:deadhead:. wrote:*   

> mi spiace per la perdita dei tuoi dati, ma il problema a monte non è che se risolvi il problema dei freeze magari non sottoponi ad eccessivo stress anche il tuo FS che così potrà lavorare in pace, sia essp xfs reiser o pokemonFS(r) ?
> 
> 

 

Il problema non è perdere i dati, perche se voglio avere un sistema stabile lo ottengo con poco sforzo. Il punto è che secondo me è una questione di principio, non capisco come mai XFS corrompe file che ha letto. Al momento del freeze l'hard disk non leggeva piu e le uniche operazioni di scrittura che aveva gia fatto erano su /tmp quindi non trovo tollerabile che corrompa i file aperti dal sistema, visto che al momento dello shutdown forzato non stava neanche facendo operazioni sul disco.

----------

## Cazzantonio

beh si questo è un problema di xfs... se ti può consolare tutti gli fs ne hanno uno... ext3 è stabilissimo ma lento e inefficiente (paragonato agli altri ovviamente... rispetto a vfat è una bomba  :Wink:  ), reiserfs è veloce ma in caso di badblocks ti da moltissimi problemi (e poi anche lui è soggettto a corruzioni... potrei citarti un caso che mi è capitato tempo fa che fa pensare...), jfs non lo conosco ma il fatto che ancora non venga considerato stabilissimo la dice lunga, idem dicasi per reiser4

Si tratta semplicemente di scegliere a seconda dell'utilizzo che si fa della macchina. Oppure inizia a sviluppare xfs e risolvi questi bug... noi te ne saremo grati  :Wink: 

----------

## Apetrini

 *Cazzantonio wrote:*   

> Oppure inizia a sviluppare xfs e risolvi questi bug... noi te ne saremo grati 

 

Non penso proprio di avere le competenze adatte...mi dispiace.

La storia comincia ad essere un po' complicata...

Infine penso che per il portatile optero' per una configurazione tipo:

/ ->  reiser4

/root e /home  -> xfs

Almeno cosi ho l'anima in pace, se si corrompe la root e' perche uso un fs troppo "sperimentale" e questo mi sta bene.

Non mi va invece di optare per un fs che ritengo sicuro e poi solo perche maltratto un po' il sistema si corrompono dei file.

Per quanto riguarda il guadagno di "autonomia" devo dire che da XFS a reiser3.6, dalle prove pratiche che avevo fatto l'anno scorso e' emerso che XFS dava un pelo meno autonomia di resier3.6, anche se quest'ultimo consumava piu cpu(comunque poca roba).

----------

## theRealMorpheu5

Dicono dalla regia che il kernel 2.6.16 ha un driver XFS mooolto migliore. L'ho provato e devo dire che ha quasi dimezzato i tempi di caricamento del sistema e un sacco di altre cose tipo KDE, Firefox...

... inoltre, formattato con 

```
mkfs.xfs -s size=512 -b size=1s
```

 lo spazio è gestito MOLTO più efficientemente. Basti pensare che coi blocchi di default avevo un Portage in 300 MB circa, ora in 170 MB scarsi.

----------

## Cazzantonio

wow prova a far crashare il pc qualche volta e se non ti sparisce nessun file allora lo rimetto su anche io   :Smile: 

----------

## .:chrome:.

 *theRealMorpheu5 wrote:*   

> Dicono dalla regia che il kernel 2.6.16 ha un driver XFS mooolto migliore. L'ho provato e devo dire che ha quasi dimezzato i tempi di caricamento del sistema e un sacco di altre cose tipo KDE, Firefox...

 

mi pare un po' audace come dichiarazione.

tanto per commentare un po' tutto il thread, io devo dire che con XFS non ho mai perso un solo bit, e sono uno che prima di mettere un FS su macchine in produzione ci pensa bene, e bisogna dire anche che il mio portatile non lo tratto benissimo, da quel punto di vista.

posso capire si si parla di kernel precedenti a 2.6.9 e 2.4.27, ma oggi come oggi corrompere un file systema XFS è davvero impossibile.

----------

## Cazzantonio

CI sta e mi piacerebbe davvero usare xfs se non fosse per il fatto che diverse volte consecutive, durante un freeze causato dai terribili driver ati, ho perso diversi file aperti al momento del crash...

Mi riprometto di fare delle nuove prove per vedere se il problema è stato risolto   :Smile: 

----------

## sometimes

mi date la conferma che

 *Quote:*   

> mkfs.xfs -varie_opzioni

 

comporta la perdita di tutti i dati?

----------

## Ic3M4n

comporta la perdita degli inode. i file sono ancora presenti sul disco, sotto forma di 0 e 1. è differente formattare una partizione da fargli 10-15 passate di /dev/zero. in ogni caso per recuperare un file devi sudare un pochino.

----------

## makoomba

tempo fa, spulciando una ml, mi sono imbattuto in questa interessante divagazione sul tema fs.

la riporto "as is"

 *Quote:*   

> You see, when you yank the power cord out of the wall, not all parts of the computer stop functioning at the same time. As the voltage starts dropping on the +5 and +12 volt rails, certain parts of the system may last longer than other parts. For example, the DMA controller, hard drive controller, and hard drive unit may continue functioning for several hundred of milliseconds, long after the DIMMs, which are very voltage sensitive, have gone crazy, and are returning total random garbage. If this happens while the filesystem is writing critical sections of the filesystem metadata, well, you get to visit the fun Web pages at http://You.Lose.Hard/ .
> 
> I was actually told about this by an XFS engineer, who discovered this about the hardware. Their solution was to add a power-fail interrupt and bigger capacitors in the power supplies in SGI hardware; and, in Irix, when the power-fail interrupt triggers, the first thing the OS does is to run around frantically aborting I/O transfers to the disk. Unfortunately, PC-class hardware doesn't have power-fail interrupts. Remember, PC-class hardware is cr*p.
> 
> Why doesn't ext3 get hit by this? Well, because ext3 does physical-block journaling. This means that we write the entire physical block to the journal, and only when the updates to the journal are committed do we write the data to the final location on disk. So, if you yank out the power cord, and inode tables get trashed, they will get restored when the journal gets replayed.
> ...

 

----------

## Cazzantonio

bene allora ho scoperto che è una feature e non un bug quella di cancellare i files aperti   :Smile: 

Temo che metterò tutto su ext3 (compresa la root che per ora era in reiserfs)   :Wink: 

----------

## .:deadhead:.

Viva i portatili con le loro batterie  :Very Happy: 

----------

## !equilibrium

 *theRealMorpheu5 wrote:*   

> Dicono dalla regia che il kernel 2.6.16 ha un driver XFS mooolto migliore. L'ho provato e devo dire che ha quasi dimezzato i tempi di caricamento del sistema e un sacco di altre cose tipo KDE, Firefox...

 

non è propriamente il 2.6.16 (anche se da questa versione in poi è possibile ri-utilizzare le 'write barrier' hardware, presenti fin dal kernel 2.4.x ma poi bloccate nel 2.6.x perchè davano problemi), ma il 2.6.17 nel quale sono state tolte gran parte delle parti 'emulate' ivi presenti e sostituite da API migliori e più efficienti e quindi maggiormente performanti; le parti 'emulate' sono in essere da tantissimo tempo ed erano necessarie in quanto il kernel non era in grado di fornirle direttamente o, se presenti, richiedevano una riscrittura delle API (cosa che è avvenuta dalla versione 2.6.14 in avanti). Il risultato ottenuto è una maggiore performance generale, soprattutto nelle scritture parallele e una maggiore affidabilità (non che prima non lo fosse sia ben intenso).

direttamente dal sito SGI (è un super-mini-riassunto-concentrato):

```

- Incore extent management rework, more efficiently using memory when working with files with large numbers of extents.

- Per-CPU superblock accounting, improving buffered I/O throughput significantly for parallel I/O workloads.

```

e per maggiori dettagli, basta dare uno scorcio rapido ai changelog del kernel 2.6.17 presenti su kernel.org, per rendersi conto nell'enormità di patches aggiunte.

----------

## Dr.Dran

Grande !equilibrium questa è una ottima notizia!!!  :Very Happy: 

----------

## drakkan

Ciao, 

sto pensando di provare xfs per il mio nuovo pc con tre dischi sata da 250GB (raid software+lvm), ho letto questi tips ma non capisco una cosa

 *!equilibrium wrote:*   

> 
> 
> se ipotizziamo di avere un array RAID 5 formato da 5 hard disk e uno strip size di 64k:
> 
> X = 64*2
> ...

 

non mi è chiaro  perchè bisogna moltiplicare per 2

riporto quanto scritto nella man page di mkfs.xfs:

```

The  sunit  suboption  is  used to specify the stripe unit for a RAID device

.....

The swidth suboption is used to specify the stripe width  for  a RAID  device

```

da questo mi sembra di capire che la moltiplicazione per due non serva,

grazie per i chiarimenti,

drakkan

----------

## drakkan

 *drakkan wrote:*   

> 
> 
> da questo mi sembra di capire che la moltiplicazione per due non serva,
> 
> 

 

mi rispondo da solo la moltiplicazione per due serve perchè quando si usa l'opzione sunit=xx il valore xx è un multiplo di 512 byte

----------

## cloc3

già il sottotitolo farà brillare gli occhi a k.gothmog   :Laughing:  .

Volevo provare xfs, ma mi sono accorto che la cosa è più complessa del previsto.

Leggendo questo e gli altri post in giro, infatti, sembrerebbe che xfs, se mal impostato, sia una vera ciofeca.

Ho un raid0 software di due dischi. Lo so, bisognerebbe fare raid5 con tre dischi, ma non li ho. E il raid contiene già altri dati che non posso spostare.

La prima partizione di prova è piccolina: 2.5G.

Volevo formattarla con l'opzione -sunit, perché se non ho capito male serve proprio a gestire il raid.

Ho fatto così:

```

mkfs.xfs -bsize=512 -dsunit=2,swidth=4 /dev/raid0/root -f

```

oppure con altri coctail di sunit,swidth.

In ogni caso, appena monto il dispositivo e ci copio dentro dei dati, si verifica questo errore fatale, che forza un reset del sistema (il kill non riesce a sbloccare il processo e nemmeno lo shutdown):

```

Jul 13 08:50:15 [kernel] raid0_make_request bug: can't convert block across chunks or bigger than 64k 170980093 4

```

Sinceramente non riesco a capire bene la situazione.

Mi sapreste dire qualcosa?

----------

## !equilibrium

/EDIT

 *cloc3 wrote:*   

> già il sottotitolo farà brillare gli occhi a k.gothmog   .
> 
> Volevo provare xfs, ma mi sono accorto che la cosa è più complessa del previsto.
> 
> Leggendo questo e gli altri post in giro, infatti, sembrerebbe che xfs, se mal impostato, sia una vera ciofeca.

 

come qualsiasi altra cosa mal configurata.

(non è certo un bug di XFS, ma è il noto problema che sta tra la sedia e il monitor   :Wink:   :Laughing:  ) <-- faccina che ride, please niente flame o attacchi personali

 *cloc3 wrote:*   

> 
> 
> ```
> 
> Jul 13 08:50:15 [kernel] raid0_make_request bug: can't convert block across chunks or bigger than 64k 170980093 4
> ...

 

se cerchi con google, troverai che il problema non è in XFS, ma è un noto bug che esiste dai tempi del kernel 2.5 (e mai realmente fixato) e generato da LVM2 + Soft RAID0. in parole povere, è un problema di LVM2, non di XFS. c'è una patch in giro da applicare al kernel (non ufficiale), e il filesystem XFS va ri-formattato con una particolare opzione per allineare il journaling con lo stripe size del soft RAID.

p.s.: non ne sono sicuro al 100% ma pare che questo bug sia dovuto al fatto che LVM2 non sia in grado di gestire correttamente un soft raid su HDs non perfettamente identici, quindi basta anche una lieve differenza di pochi MB tra i due HDs e LVM2 non riesce a riallocare correttamente i settori in fase di scrittura. (faccio notare che si stà andando terribilmente OT rispetto al thread originario)

----------

## cloc3

 *!equilibrium wrote:*   

> 
> 
> se cerchi con google, 

 

ci hai azzeccato in tutto. Su google ci sono post del 2003 su questo argomento, ma la "documentazione" è un po' troppo dispersa per le mie capacità di sintetizzare una soluzione. essendo ot qui, credo che ti scriverò in mp.

hai ragione anche a dire chi il mio lvm2 è collocato su due partizioni leggermente diverse. non sono stato capace di farle identiche, perché i due dischi usavano una geometria fisica (cilindri - blocchi -settori ?) differente.

non è ot, invece, chiedere un cenno relativo alla scelta dei valori di sunit e swidth. i miei sono corretti, sono efficienti, per un filesystem che deve contenere il sistema operativo e i programmi principali?

----------

## !equilibrium

 *cloc3 wrote:*   

> non è ot, invece, chiedere un cenno relativo alla scelta dei valori di sunit e swidth. i miei sono corretti, sono efficienti, per un filesystem che deve contenere il sistema operativo e i programmi principali?

 

faccio un esempio concreto così da spiegare per bene questo concetto una volta per tutte; prendo il tuo caso specifico e lo userò come esempio, quindi un RAID0 di 2 unità con uno stripe size di 32K (valore da me inventato visto che non l'hai riportato nei precedenti post).

PREMESSA: in un array RAID, durante i processi di scrittura, un file viene spezzato in blocchi più piccoli, i quali vengono salvati sulle varie unità dell'array; la dimensione di questi blocchi è specificata in /etc/raidtab tramite il parametro chunk-size.

sunit rapprenta la grandezza dei blocchi in cui verrà suddiviso un file durante i processi di I/O (quindi rispecchia il chunk-size dell'array) e deve essere espresso in multipli di 512byte, come dice lo stesso man di mkfs.xfs:

```
The  sunit  suboption  is  used  to specify the stripe unit for a RAID device or a logical volume.  The suboption

              value has to be specified in 512-byte block units.  Use the su suboption to  specify  the  stripe  unit  size  in

              bytes.   This suboption ensures that data allocations will be stripe unit aligned when the current end of file is

              being extended and the file size is larger than 512KiB.  Also inode allocations and  the  internal  log  will  be

              stripe unit aligned.

```

cioè nel caso dell'esempio:

32 * 1204 = 32768 byte (chunk-size espresso in byte)

32768 / 512 = 64 (chunk-sze espresso in multipli di 512byte)

quindi:  -d sunit=64

p.s.: per chi non l'avesse notato, l'operazione appena citata si può semplificare prendendo l'intero del valore del chunksize e moltiplicarlo per 2 (determinato da 1024 / 512), come ho riportato nel TIP alla sezione 6- Stripe Size e RAID.

swidth indica la capacità massima dello strip-size dell'array, raggiunto il quale il filesystem torna a scrivere alla prima unità che compone il raid, e deve essere espresso in multipli di 512byte. In parole povere, con questo parametro si specifica in quante parti un file deve essere spezzato, o meglio ancora, su quante unità dell'array un dato file deve essere suddiviso; questo valore si calcola moltiplicando il chunk-size per il numero totale delle unità, fatta eccezione per le unità di parità (che non devono essere conteggiate).

nel caso dell'esempio:

2 * 32K = 64K (stripe-size totale espresso in Kbyte) 

64K = 65536 byte (stripe-size totale espresso in byte)

65536 / 512 = 128 (stripe size totale espresso in multipli di 512byte)

quindi:  -d sunit=64 swidh=128

p.s.: per chi non l'avesse notato, l'operazione appena citata si può semplificare prendendo il valore di sunit e moltiplicandolo per 2 (determinato da 1024 / 512).

cosa cambia nel filesystem con questi nuovi settaggi?

il filesystem conoscendo la dimensione logica dell'array è in grado di suddividere il file che deve scrivere/leggere in buffer specifici e salvarli in un ordine di unità efficiente, cioè nel caso dell'esempio, prenderebbe i primi 32K del file e li salverebbe nel primo disco, poi il successivo blocco lo salverebbe nel secondo disco, a questo punto il filesystem raggiunge la capacità massima dello stripe e ricomincia da capo, partendo dal primo disco e passando al secondo e così via. Siccome XFS è in gradi eseguire processi di I/O in parallelo entrambi gli HDs verrebbero sfruttati contemporaneamente e non a casaccio (il filesystem potrebbe decidere di copiare i primi 4 blocchi del file nel primo disco, poi i successi 2 nel secondo e un altro blocco nel primo e i successi 20 nel secondo e così via, senza logica alcuna), sfruttando al meglio l'hardware. inoltre i buffer del filesystem e del journaling sarebbero allineani con lo stripe size dell'array e quindi tutti i processi di I/O non sarebbero rallentati dalle operazioni necessarie per adattare i buffers (perchè ovviamente di dimensioni sempre diverse). In soldoni, la lettura/scrittura dei files è molto + fluida e prestante.

(Va da se che un filesystem XFS configurato alla c***o su un RAID, avrà pessime performance   :Wink:   )

ultima TIP: per chi ha controllers RAID 3ware, determinate il chunk-size ottimale per il vostro array tramite i valori consigliati dall'utility tw_cli e non spannometricamente tramite Google   :Wink: 

----------

## Dr.Dran

 *!equilibrium wrote:*   

> ultima TIP: per chi ha controllers RAID 3ware, determinate il chunk-size ottimale per il vostro array tramite i valori consigliati dall'utility tw_cli e non spannometricamente tramite Google  

 

Aggiungo che il parametro lo si può ottenere anche entrando al boot nella utility BIOS del controller RAID controllando le informazioni del controller creato o esistente   :Very Happy: 

----------

## riverdragon

Ad eccezione del filesystem di boot, che è ext2, ho tutti i filesystem di gentoo in xfs (/, /home e una partizione "di salvataggio").

Noto ora questo splendido howto che ho trovato cercando alcuni tweaks per i miei filesystem. Sembra infatti da bootchart che la mia zavorra all'avvio sia proprio il disco.

Chiudendo la parentesi introduttiva, segnalo a equilibrium che in un articolo che ho trovato tramite google si segnala un'ottimizzazione che va in direzione opposta a quanto da lui spiegato, riguarda i gruppi di allocazione: viene detto di diminuire i gruppi di allocazione al momento della formattazione per ridurre l'overhead generato dall'accesso multiplo al disco, consigliando un valore di 4->8 (sempre tenendo conto di avere almeno un ag ogni 4GB); in questo howto invece viene consigliato di aumentarne il numero.

Poco dopo, nello stesso articolo, viene menzionata un'ulteriore opzione da aggiungere a fstab, l'opzione osyncisdsync.

EDIT2: avevo inserito i risultati di bonnie con tre opzioni di mount differenti (rw,barrier; rw,noatime,nodiratime,barrier; rw,noatime,nodiratime,osyncisdsync,barrier) ma l'output è formattato sufficientemente male che non si capiva granché, e il forum non sembra permettere caratteri monospace. Quando sarà leggibile li reinserirò.

----------

## power83

A che serve nodiratime?

----------

## .:deadhead:.

 *riverdragon wrote:*   

> ma l'output è formattato sufficientemente male che non si capiva granché, e il forum non sembra permettere caratteri monospace. Quando sarà leggibile li reinserirò.

 uppalo da qualche parte e poi linkalo qui  :Wink: 

 *power83 wrote:*   

> A che serve nodiratime?

 a non cambiare l'acces time per le directory, è il corrispettivo di noatime

----------

## riverdragon

Provate a vedere se da qui si vede qualcosa.

Come appunto, queste sono due righe dal mio /var/log/messages riguardanti l'opzione osyncisdsinc e l'opzione di mount logbsize:

```
Sep 22 15:48:40 tomnote XFS: osyncisdsync is now the default, option is deprecated.

Sep 22 15:48:40 tomnote XFS: logbuf size for version 1 logs must be 16K or 32K
```

La questione sull'uso della prima opzione sparisce, invece sorge il problema di cosa voglia dire quel "version 1" che mi impedisce di impostare logbsize a 64k.

----------

## Dr.Dran

Beh la risposta al tuo quesito è facile, devi sapere che xfs ha 2 versioni di logging per il journal del filesystem e quindi ti consiglia con tale versione di impostare un buffer di massimo 32K.

Per utilizzare la versione 2 devi riformattare il filesystem con la apposita istruzione.

Cheers

Franco  :Very Happy: 

----------

## riverdragon

Trovata, l'opzione -l version=2. Grazie!

Alla fine, è meglio aumentare il numero di ag rispetto al default o è meglio aumentarlo? Non mi è ancora chiaro, e vorrei fare un'unica riformattazione.

----------

## .:deadhead:.

```
-l version=2
```

 è una correzione che equilibrium dovrebbe decidersi ad includere nel primo post. Son settimane che si ripropone di aggiungerla  :Very Happy: 

----------

## mrfree

Ho appena terminato la migrazione per la mia home da reiserfs3 a xfs quindi non posso ancora dare pareri da utilizzatore veterano, ho però notato che mentre subito dopo la creazione del filesystem lo spazio libero è maggiore rispetto a reiserfs ora che ho rsync-ato e riempito di nuovo la mia home lo spazio disponibile è parecchio di meno!

df riporta con xfs 2403752 blocchi disponibili mentre con reiserfs erano 3208972

Questi i parametri che ho utilizzato per formattare la partizione

```
mkfs.xfs -f -d unwritten=0 -l size=64m,version=2 /dev/vg/home
```

----------

## riverdragon

In MB quanto sarebbe la differenza? E cosa c'entra la home con il sync (suppongo sia quello di portage)?

Equilibrium, quando aggiorni la guida?  :Crying or Very sad: 

----------

## Ic3M4n

per spostare i file alcune persone, me compreso, preferiscono rsync a cp.

per quanto riguarda la formattazione io avrei utilizzato anche l'opzione -b size=512 che permette di ridurre spazio sui file molto piccoli.

----------

## mrfree

 *riverdragon wrote:*   

> In MB quanto sarebbe la differenza?

 Purtroppo mi sono segnato solo i blocchi   :Sad:  Però, se non erro, la perdita dovrebbe essere, a memoria, di almeno 1GB

 *Ic3M4n wrote:*   

> per quanto riguarda la formattazione io avrei utilizzato anche l'opzione -b size=512 che permette di ridurre spazio sui file molto piccoli.

 Non è un po' pochino? Anche secondo le linee guida di SGI [pp 7 e seguenti] per filesystem di queste dimensioni (parliamo di 48GB) la dimensione consigliata è 4KB. Comunque si tratta di una home quindi parliamo magari di file di qualche MB (musica, video) un bsize così basso potrebbe influenzare negativamente le performance dell'intero filesystem, o no?

Poi il filesystem precedente era reiserfs3 (partizione formattata con i parametri di default) se anche questo adotta 4KB come dimensione dei blocchi da cosa potrebbe dipendere tale perdita di spazio? Comincio a pensare alle impostazioni del log...

----------

## Ic3M4n

reiser utilizza 512 di default che io sappia.

----------

## riverdragon

Avevo scritto un messaggio, ora non lo vedo... boooh. Comunque, 1 gigabyte è un'enormità, prova (se puoi) a riformattare il filesystem senza opzioni particolari e a vedere che succede.

----------

## mrfree

 *Ic3M4n wrote:*   

> reiser utilizza 512 di default che io sappia.

 Ho provato su un'altra mia partizione 

```
# debugreiserfs /dev/vg/usr | grep Blocksize

debugreiserfs 3.6.19 (2003 www.namesys.com)

Blocksize: 4096
```

Credo che appena possibile proverò a riformattare con le impostazioni di default per capire se cambia qualcosa...

----------

## Cazzantonio

@!equilibrium:

Volevo chiederti un consiglio...

Ho un notebook e un server in cui volevo iniziare a migrare le partizioni ext3 verso xfs.

Nel notebook ho una partizione root più una /home che attualmente sono in ext3.

Nel server ho una root e una partizione di dati GROSSA (320 giga) in ext3, più un paio di partizioni modeste (ma di frequente utilizzo) dove ho finora sperimentato la resistenza di xfs.

Il mio utilizzo del notebook è assolutamente normale se non fosse che occasionalmente ci lancio sopra dei programmi che occupano per svariate ore il 100% della cpu e mi scrivono giga e giga (anche una ventina, scanditi con contiunazione su tutte le ore del processo) sulla partizione /home.

Il mio utilizzo del server è invece, per ora, solo di storage domestico e di media player (sostanzialmente sta fisso acceso ma non fa un granché).

Le mie priorità sono garantire innanzitutto la sicurezza dei dati (fondamentale soprattutto sulle home e sulle partizioni dati) e secondariamente minimizzare gli accessi a disco; non mi interessano particolarmente le prestazioni velocistiche (se ci sono tanto meglio ma non sacrificherei niente per averle).

Entrambi hanno parecchia ram (più di un giga) purtroppo non ECC (quando sarò ricco provvederò).

Il server è sotto un UPS; il portatile invece, ovviamente, ha una batteria   :Wink: 

Volevo chiederti, secondo il tuo giudizio, quale potrebbe essere un valore per logbufs e logbsize per le partizioni sia sul notebook che sul server.

Quello che mi crea dubbi è quali siano le controindicazioni per un valore alto di logbsize, ovvero se ci siano più rischi di perdere dati a scapito di una discutibile riduzione degli accessi a disco.

Inoltre sono curioso di sapere come si faccia a capire se gli hd in mio possesso (tutti dei seagate barracuda) hanno le write-barriers hardware.

P.S. la partizione dati del server temo di non poterla migrare visto che non so bene dove trovare lo spazio per beckuppare tutti i dati che contiene.

----------

## !equilibrium

 *Cazzantonio wrote:*   

> Volevo chiederti, secondo il tuo giudizio, quale potrebbe essere un valore per logbufs e logbsize per le partizioni sia sul notebook che sul server. Quello che mi crea dubbi è quali siano le controindicazioni per un valore alto di logbsize, ovvero se ci siano più rischi di perdere dati a scapito di una discutibile riduzione degli accessi a disco.

 

l'aumento dei buffer di log ha solo lo scopo di ridurre gli accessi al disco e di conseguenza aumentare le prestazioni di scrittura/lettura, quindi dal punto di vista della sicurezza dei dati non perdi nulla e non guadagni nulla. Siccome il tuo scopo ultimo non sono le performance, ma solo una riduzione degli accessi allora ti consiglio di usare i valori che ho riportato nel mio tutorial (cioè il doppio dei valori di default), credo che siano più che sufficienti.

 *Cazzantonio wrote:*   

> Inoltre sono curioso di sapere come si faccia a capire se gli hd in mio possesso (tutti dei seagate barracuda) hanno le write-barriers hardware.

 

ehehehehe

sugli SCSI è facile saperlo, ti viene riportato tra le mille e una funzionalità rilevate da sdparm.

sui PATA/SATA non saprei, o meglio, sui SATA dovresti riuscire ad usare sdparm, sui PATA non ho idea.

comunque se usi XFS, e monti una partizione di un HD che non supporta le write barrier hardware, ti viene mostrato a video un messaggio che ti informa:

Filesystem "XXXX": Disabling barriers, not supported by the underlying device

se il messaggio non ti esce a video in fase di mount vuol dire che hai pieno supporto alle write barrier hardware del drive  :Wink:  (se maometto non va alla montagna ... )

p.s.: sorry per la lunga attesa alla mia risposta.

----------

## Cazzantonio

 *!equilibrium wrote:*   

> Filesystem "XXXX": Disabling barriers, not supported by the underlying device
> 
> se il messaggio non ti esce a video in fase di mount vuol dire che hai pieno supporto alle write barrier hardware del drive  (se maometto non va alla montagna ... )

 

Avevo già controllato e non compare... comunque per sicurezza forzo l'utilizzo delle barriers in fase di mount   :Wink: 

 *Quote:*   

> p.s.: sorry per la lunga attesa alla mia risposta.

 Grazie, non ti preoccupare   :Smile: 

----------

## Kernel78

Domandina, ho provato a modificare il mio fstab per fare delle prove *Quote:*   

> /dev/md0                /boot           xfs             barrier,noauto,noatime 1 2

 ma quando monto /boot mi ritrovo cmq

```
# dmesg | tail

nfsd: unexporting all filesystems

eth1: link down

eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

eth1: link down

eth1: link up, 100Mbps, full-duplex, lpa 0x41E1

ISO 9660 Extensions: Microsoft Joliet Level 3

ISO 9660 Extensions: RRIP_1991A

Filesystem "md0": Disabling barriers, not supported by the underlying device

XFS mounting filesystem md0

Ending clean XFS mount for filesystem: md0

```

Mi sembra di capire che non è proprio una bella cosa ...

Disabilito cmq la write cache o no ?

Scusate le domande stupide ma oggi mi sento più rimbambito del solito ...

----------

## !equilibrium

 *Kernel78 wrote:*   

> 
> 
> ```
> Filesystem "md0": Disabling barriers, not supported by the underlying device
> 
> ...

 

no, e' tutto normale.

md0 sicuramente e' un software raid, in tal caso le barrier vengono disabilitate automaticamente dal kernel, perche' md0 non e' una periferica vera ma e' virtuale (sono due partizioni fuse in una) e quindi il kernel non sa come gestire alcuni aspetti della periferica.

per quanto concerne la write cache, disabilita pure, metti -W0 in /etc/conf.d/hdparm per tutti i drive e sei a posto.

/NOTA: prometto che entro oggi aggiorno la presente guida.

----------

## riverdragon

 *!equilibrium wrote:*   

> /NOTA: prometto che entro oggi aggiorno la presente guida.

 Alé, sagra  :Exclamation:   Grande equilibrium!

----------

## Scen

Sto leggendo questo utilissimo topic (grazie 1000 equilibrium  :Wink:  ) per provare XFS su un RAID1 software (su 2 dischi SCSI).

Purtroppo mi ritengo abbastanza ignorante in materia di FS e simili  :Embarassed:  , per cui mi tocca chiedere: cos'è lo stripe size? Come lo identifico/configuro? E' relativo al disco, al filesystem, alla configurazione RAID, o cosa?

Grazie a chiunque mi darà qualche delucidazione in merito  :Razz: 

----------

## riverdragon

Ho riformattato la root secondo le indicazioni aggiornate. Funziona, vedrò come e quanto col tempo, più avanti riformatterò anche la home.

Un appunto riguardo la disabilitazione della write cache: mi viene segnalato questo errore

```
tomnote ~ # /etc/init.d/hdparm restart

 * Service hdparm stopping

 * WARNING:  you are stopping a boot service.

 * Service hdparm stopped

 * Service hdparm starting

 * Running hdparm on /dev/hda ... [ ok ]

 * Running hdparm on /dev/hdb ...

 HDIO_DRIVE_CMD(setcache) failed: Input/output error [ ok ]

 * Service hdparm started
```

E' relativo al fatto che di default /etc/conf.d/hdparm presenta le opzioni alla voce pata_all_args="..." e il tentativo di disabilitare la write cache dal lettore cd genera un errore; modificando la configurazione in questo modo

```
#pata_all_args="-d1 -c3 -u1 -W0 -k1 -K1"

hda_args="-d1 -c3 -u1 -W0 -k1 -K1"

cdrom0_args="-d1 -c3 -u1 -k1 -K1"
```

gli errori non si ripresentano.

----------

## !equilibrium

 *riverdragon wrote:*   

> E' relativo al fatto che di default /etc/conf.d/hdparm presenta le opzioni alla voce pata_all_args="..." e il tentativo di disabilitare la write cache dal lettore cd genera un errore

 

bhe mi pare ovvia la risposta: un lettore CDROM non e' un harddrive.

va da se' che nessun lettore cd ha insito nessun genere di meccanismo di lettura/scrittura per migliorare le performance dei processi I/O (write cache, barrier ecc).

----------

## riverdragon

Certo, ma inizialmente il file presenta le opzioni legate a pata_all_args, quindi viene immediato fare le modifiche lì. Se aggiungi la postilla al tuo howto si evita un po' di tachicardia  :Laughing:   come ne ho avuta io dopo che, avendo riformattato la partizione, ho letto un "input/output error".  :Laughing: 

----------

## !equilibrium

 *Scen wrote:*   

> Purtroppo mi ritengo abbastanza ignorante in materia di FS e simili  , per cui mi tocca chiedere: cos'è lo stripe size? Come lo identifico/configuro? E' relativo al disco, al filesystem, alla configurazione RAID, o cosa?

 

lo stripe size e' relativo al RAID.

se leggi tutto il thread mi pare venga anche spiegato nel dettaglio.

p.s.: proprio ora ho aggiornato pesantemente tutta la guida.

----------

## Kernel78

 *!equilibrium wrote:*   

> [6] Stripe Size e RAID
> 
> Per chi dispone di un sistema basato su RAID, puÃ² trarre notevoli benefici in termini di prestazioni specificando al filesystem la dimensione dello stripe size e il numero di hard disk coinvolti nel RAID. In questo modo i buffers di lettura e scrittura saranno allineati con lo strip size dell'array RAID evitando inutili perdite di tempo al filesystem dovuti allo svuotamento/riempimento dei buffers in modo asincrono (e questo rallenta parecchio le performance del filesystem!!).
> 
> Per formattare il filesystem con le impostazioni specifiche per il proprio array RAID bisogna usare queste opzioni:
> ...

 

Premessa: per il momento io ho un raid 5 sw composto da 3 hd e quando l'ho creato ho formattato con opzioni standard.

Domanda: vale la pena spostare tutto e formattare con parametri calcolati sulle mie esigenze quando sto già valutando di aggiungere un 4° hd al raid (anche se non nell'immediato futuro) ?

----------

## djinnZ

 *!equilibrium wrote:*   

> p.s.: proprio ora ho aggiornato pesantemente tutta la guida.

 

mi pare che ti sei dimenticato dell'opzione -b (e relativa -i) per cercare di ottimizzare l'occupazione di spazio su volumi di archiviazione. Che ne pensi?

----------

## !equilibrium

 *djinnZ wrote:*   

> mi pare che ti sei dimenticato dell'opzione -b (e relativa -i) per cercare di ottimizzare l'occupazione di spazio su volumi di archiviazione. Che ne pensi?

 

ho saltato volutamente quella parte per motivi che non sto qua ora a spiegare, a breve integrerò una spiegazione dettagliata per -b, -n, e -s per l'ottimizzazione dello spazio   :Wink: 

----------

## .:deadhead:.

BELLAAA!! Non vedo l'ora!

----------

## bandreabis

Dovo trovo questa guida?

Sbav sbav.

----------

## !equilibrium

 *bandreabis wrote:*   

> Dovo trovo questa guida?
> 
> Sbav sbav.

 

p.s.: leggere attentamente il primo post del thread, grazie   :Rolling Eyes: 

----------

## bandreabis

In realtà stavo cercando info riguardo a:

 *!equilibrium wrote:*   

> ho saltato volutamente quella parte per motivi che non sto qua ora a spiegare, a breve integrerò una spiegazione dettagliata per -b, -n, e -s per l'ottimizzazione dello spazio  

 

E poi non ho capito su quali partizioni sia utile usare xfs considerando che ho partizioni separate per /, /usr, /var, /home, /documenti.

----------

## !equilibrium

 *bandreabis wrote:*   

> In realtà stavo cercando info riguardo a:
> 
>  *!equilibrium wrote:*   ho saltato volutamente quella parte per motivi che non sto qua ora a spiegare, a breve integrerò una spiegazione dettagliata per -b, -n, e -s per l'ottimizzazione dello spazio   

 

la descrizione per quelle opzioni sono state incluse nel man: man mkfs.xfs.

sono le opzioni per settare i block/sector/directory size.

 *bandreabis wrote:*   

> E poi non ho capito su quali partizioni sia utile usare xfs considerando che ho partizioni separate per /, /usr, /var, /home, /documenti.

 

XFS è un FS e come tale non è diverso dagli altri e non ha nessun genere di limitazione (paragonato ai FS inclusi nel kernel) quindi non ha molto senso come domanda.

----------

## bandreabis

Se ho capito bene, da varie risposte al topic, conviene formattare le partizioni con 

```
mkfs.xfs -l lazy-count=1
```

montare le partizioni con le opzioni in fstab 

```
barrier,nodiratime,noatime
```

 disattivando la write cache sui dischi (anche se con i PATA crollano le prestazioni).

Ho letto bene?

----------

## !equilibrium

 *bandreabis wrote:*   

> Se ho capito bene, da varie risposte al topic, conviene formattare le partizioni con 
> 
> ```
> mkfs.xfs -l lazy-count=1
> ```
> ...

 

sì

 *bandreabis wrote:*   

> montare le partizioni con le opzioni in fstab 
> 
> ```
> barrier,nodiratime,noatime
> ```
> ...

 

barrier solo se il tuo HDD supporta le Write Barrier.

nodiratime,noatime non sono opzioni di XFS e non servono per velocizzarlo o ottimizzarlo.

----------

## xdarma

 *bandreabis wrote:*   

> montare le partizioni con le opzioni in fstab 
> 
> ```
> barrier,nodiratime,noatime
> ```
> ...

 

Se non mi sbaglio: noatime implica nodiratime. Quindi basta noatime.

noatime non è specifico di xfs ma "generico unix" e, a memoria, disabilita le scritture di access time su disco diminuendo il "traffico". Non è detto che questo risparmio si traduca in aumento di prestazioni visibile, magari l'impatto è minimo.

Disabilitare la write-cache del disco, secondo me, non si tradurrà in un "crollo" delle prestazioni.

Mi verrebbe da dirti che la differenza maggiore sarà un filesystem più sicuro, ma fai prima a fare una prova e dirmi cosa ti sembra  ;-)

----------

## !equilibrium

 *xdarma wrote:*   

> Se non mi sbaglio: noatime implica nodiratime. Quindi basta noatime.

 

sì esatto, ma ci sono software che con l'opzione noatime possono smettere di funzionare correttamente, io consiglio di usare relatime (man mount):

```
relatime

     Update inode access times relative to modify or change time.  Access time is only updated if the previous access time

     was earlier than the current modify or change time. (Similar to noatime, but doesn't break mutt or other applications

     that need to know if a file has been read since the last time it was modified.)
```

 *xdarma wrote:*   

> noatime non è specifico di xfs ma "generico unix" e, a memoria, disabilita le scritture di access time su disco diminuendo il "traffico". Non è detto che questo risparmio si traduca in aumento di prestazioni visibile, magari l'impatto è minimo.

 

sui desktop / notebook è un buon modo per risparmiare corrente / batteria mantenendo l'HDD in stato di standy per tempi molti più lunghi (alzino la mano quanti di voi hanno bisogno di verificare la data di ogni singolo file che creano) e allo stesso tempo l'HDD entra in standby molto prima se ha meno operazioni I/O da fare; per un server invece il discorso cambia, l'incremento di performance è notevole, soprattutto per i file server o i mail server, dove gli accessi I/O sono presenti 24h/7 quindi il poter risparmiare qualche decimo di secondo per ogni processo I/O si tramuta in un sensibile aumento della responsività del server.

 *xdarma wrote:*   

> Disabilitare la write-cache del disco, secondo me, non si tradurrà in un "crollo" delle prestazioni.

 

sui vecchi PATA sì, il crollo è dell'ordine dei 2/3 delle performance originarie, sui SATA invece non è rilevabile, ma il problema non si pone, chi usa ancora i PATA al giorno d'oggi?   :Laughing:  p.s.: e con pochi euro ci si può comprare un nuovo SATA che da solo velocizzerà x10 le performance del FS.

 *xdarma wrote:*   

> Mi verrebbe da dirti che la differenza maggiore sarà un filesystem più sicuro, ma fai prima a fare una prova e dirmi cosa ti sembra  

 

c'è da tenere a mente che nonostante siano passati anni dalla sua segnalazione, nel kernel linux è ancora presente il famoso bug che uccide le performance degli I/O quando la cpu è sotto forti carichi: prima che me lo chiediete, sì, il bug è ancora presente nella versione 2.6.36 rilasciata di recente e sì, non verrà risolto nemmeno per la versione 2.6.37.

----------

## bandreabis

Il prossimo mio PC allora sarà 10 volte più veloce!!   :Laughing: 

----------

## !equilibrium

Per la gioia di chi ama fare FUD, un po' di benchmark seri.

----------

