[TIP] migliorare le performance di SGI XFS Filesystem

[riverdragon]

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

Alé, sagra Grande equilibrium!

[Scen]

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

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?

Grazie a chiunque mi darà qualche delucidazione in merito

[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

Code: Select all

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

Code: Select all

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

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 come ne ho avuta io dopo che, avendo riformattato la partizione, ho letto un "input/output error".

[!equilibrium]

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]

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

Code: Select all

mkfs.xfs -d sunit=X -d swidth=Y

dove X è dato dal valore dello strip size moltiplicato per 2, e Y è dato dal valore dello strip size moltiplicato per il numero degli hard disk presenti nell'array (esclusi quelli di parità ) per 2.

facciamo qualche esempio pratico.

se ipotizziamo di avere un array RAID 5 formato da 5 hard disk e uno strip size di 64k:

X = 64*2
Y = 64*4*2

se ipotizziamo un array RAID 0 formato da 3 hard disk con uno strip size di 128K:

X = 128*2
Y = 128*3*2

N.B.: riporto la mia esperienza personale in merito a questo punto su un mio fileserver personale (RAID 5 con strip size 64K composto da 10 sata). Prima di effettuare la formattazione come spiegato al punto (6) il RAID aveva una capacità su lettura singola (non letture multiple in parallelo) pari a circa ~220MB/s, dopo aver riformattato l'array con le ottimizzazioni sopra spiegate la capacità in lettura singola è stata pari a ~400MB/s (entrambi i valori li ho rilevati con lo stesso strumento di benchmark)

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]

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]

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

[.:deadhead:.]

BELLAAA!! Non vedo l'ora!

[bandreabis]

Dovo trovo questa guida?
Sbav sbav.

[!equilibrium]

Dovo trovo questa guida?
Sbav sbav.

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

[bandreabis]

In realtà stavo cercando info riguardo a:

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]

In realtà stavo cercando info riguardo a:

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.

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

Code: Select all

mkfs.xfs -l lazy-count=1

montare le partizioni con le opzioni in fstab

Code: Select all

barrier,nodiratime,noatime

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

[!equilibrium]

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

Code: Select all

mkfs.xfs -l lazy-count=1

sì

montare le partizioni con le opzioni in fstab

Code: Select all

barrier,nodiratime,noatime

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

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]

montare le partizioni con le opzioni in fstab

Code: Select all

barrier,nodiratime,noatime

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

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]

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

Code: Select all

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

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.

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? p.s.: e con pochi euro ci si può comprare un nuovo SATA che da solo velocizzerà x10 le performance del FS.

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

[!equilibrium]

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