[TIP] migliorare le performance di SGI XFS Filesystem

[drakkan]

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 .

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ì:

Code: Select all

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):

Code: Select all

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

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 ) <-- faccina che ride, please niente flame o attacchi personali

Code: Select all

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?

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]

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]

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:

Code: Select all

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 )

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

[Dr.Dran]

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

[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:.]

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

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:

Code: Select all

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

[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:.]

Code: Select all

-l version=2

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

[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

Code: Select all

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?

[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]

In MB quanto sarebbe la differenza?

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

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]

reiser utilizza 512 di default che io sappia.

Ho provato su un'altra mia partizione

Code: Select all

# 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

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]

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.

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 (se maometto non va alla montagna ... )

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

[Cazzantonio]

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

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

Grazie, non ti preoccupare

[Kernel78]

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

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

ma quando monto /boot mi ritrovo cmq

Code: Select all

# 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]

Code: Select all

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 ...

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.