Newsgroup: it.comp.hardware.storage
Titolo: SSD in RAID, allineamento ai 4k e TRIM

Ho un paio di questi qui
http://www.ocztechnology.com/ocz-vertex-2-sata-ii-3-5-ssd.html
da 120Gb, stavo pensando di collegarli ad un controller SAS RAID
basato su LSI 2108 e metterli in raid1.
I miei dubbi sono:
1) come gestire l'allineamento delle partizioni, visto che il SO non
vede il disco fisico ma il disco virtuale esposto dalla scheda raid?
Questa è facile: ora provo a creare il raid, poi sfilo un disco e vedo
come sono le partizioni create.
2) come gestire il TRIM? Il SO è linux, posso pure passare il TRIM sia
automatico che manuale, ma arriverà al disco?
3) il controller LSI prevede un tal 'SSD Guard', ma che sarà mai?
Spero che qualcuno abbia le risposte :-)
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 come sono le partizioni create.
Risposta: la partizione creata dal SO č allineata sul disco usato.
Quindi:
SO => LSI 2108 => RAID1 con 2xVertex2 = allineamento come richiesto dal SO.


 3) il controller LSI prevede un tal 'SSD Guard', ma che sarà mai?
non ne avevo mai letto niente, comunque e' una funzionalita'
dei controller MegaRAID che prevede una unita' hot spare
per i volumi RAID composti da SSD, in caso di problemi
ad uno degli SSD membri (tramite SMART?), provvede
a ricreare il volume con l'unita' spare disabilitando quella
"difettosa", secondo me e' piu' utile in configurazioni striping
che mirroring (a meno che tu non voglia aumentare ulteriormente
il livello di affidabilita')  , dal sito LSI:
http://www.lsi.com/downloads/Public/Solid%20State%20Storage/Solid%20State%20Storage%20Common%20Files/MR_FastPath_PB_083110.pdf
come mai una soluzione RAID-1 ? (server?)
ciao
luca

 SO => LSI 2108 => RAID1 con 2xVertex2 = allineamento come richiesto dal SO.
Bene.
Ora, se lo usi, ricordati di "allineare" anche LVM.
# pvcreate --dataalignment 128k ...
etc. etc.
E poi di allineare il fs - che sarà ext4 - alla dimensione
dell'unità di cancellazione dell'SSD (cosa che era vitale coi
primi SSD, ora pare sia meno importante ma male non fa di certo):
mi pare 512KB col Vertex.
# mkfs -t ext4 -E stripe-width=128 ...
(4KB*128=512KB)
E altre cose, come la scelta dell'I/O scheduler (evita
assolutamente anticipatory e cfq. Deadline e noop vanno bene, ma
avendo tu un controller hardware probabilmente sarà meglio noop).
Qui ci sono un po' di tricks e suggerimenti made in OCZ:
http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment&highlight=linux
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
http://cleanenergy.harvard.edu/
 
http://spin.fh-bielefeld.de/
 
http://www.gpugrid.net/
 

 # pvcreate --dataalignment 128k ...
128 o quel che è giusto, non saprei. Magari 512.


 (4KB*128=512KB)
questa parte la ignoro, pero' il Vertex 2 puo' montare
diversi tipi di memorie (Hynix 32nm, Intel/Micron 34nm,
i nuovi anche Intel/Micron 25nm, ecc..) , se puo'
allineare ad 1MiB e' meglio (va bene un po' per tutto)
ma non conosco controindicazioni sul FS ..
vale anche per l'allineamento iniziale della partizione
(se non ricordo male Linux allinea a 256KiB di default)
ciao
luca

 come mai una soluzione RAID-1 ? (server?)
Si, ci voglio appoggiare un server sql che fa parecchie richieste
contemporanee di piccola entità.
Ma il vertex2 non ha un GC interno?


 
http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment&highlight=linux
Grazie, non conoscevo la pagina, è interessante.


 (4KB*128=512KB)
Prendili con le molle (poche prove), ma dai comunque un'occhiata a questi 
test:
stripe width a 128
Version 1.03d       ------Sequential Output------ --Sequential 
Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per 
Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec 
%CP
mioserver        4G 132385  76 157223  17 43979   8 176838  94 201898  14 
9975  26
                    ------Sequential Create------ --------Random 
Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
%CP
                128 37779  69 +++++ +++ 16664  22 50907  96 +++++ +++ 37361 
57
stripe width non indicato
Version 1.03d       ------Sequential Output------ --Sequential 
Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per 
Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec 
%CP
mioserver         4G 158236  88 229168  26 54574   9 162679  86 285498  19 
10488  27
                    ------Sequential Create------ --------Random 
Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
%CP
                128 51914  94 +++++ +++ 14671  18 44012  81 +++++ +++ 19165 
27
In pratica con lo stripe a 512K il consumo di CPU si abbassa e con lui il 
throughput
e i seek. Il random create e delete invece migliora (e mi sembra quasi 
ovvio).
Per il mio utilizzo toglier� lo stripe width, mi � sufficiente avere un seek 
alto e
un buon throughput.
Credo anche di aver capito che il firmware della LSI gestisce il TRIM, 
perch�
disattivandolo la velocit� di cancellazione aumenta e di molto.
In questo momento sto ricostruendo un altro volume sullo stesso backplane
quindi i dati possono essere falsati dal maggior carico della scheda sas.
Appena finita la ricostruzione faccio un secure erase ai due ssd ed eseguo
un po' di prove in pi�.
Se avete in mente qualche test che pu� interessare (come condizioni, per
i bench qui posso usare in pratica solo bonnie++) scrivetemelo che lo 
eseguo.


 Ma il vertex2 non ha un GC interno?
si' ma e' poco efficiente e richiede periodi di idle consistenti
(in un'applicazione server e' impensabile)
se sei in fase di installazione e verifica preliminare, crea una
partizione di circa 200GB e lascia il resto per la spare area
(in pratica come per i primi modelli di Vertex 2 e Pro)
considera che il TRIM , in una configurazione con MySQL,
e' l'ultimo dei tuoi problemi , quando ci sono molte
letture e scritture casuali i controller consumer vanno
in stallo
non so se puo' esserti utile, prova anche a spostare il log
di MySQL in un secondo volume mirror, anche con dischi
meccanici (ho fatto solo pochi test a tal proposito ma
avevo letto su Anand che migliora le prestazioni generali)
ciao
luca

 avevo letto su Anand che migliora le prestazioni generali)
Proverò anche questo, è interessante.
Così le scritture andrebbero sul disco meccanico e si
consoliderebbero successivamente.


 consoliderebbero successivamente.
chiedo ancora scusa ma i test li hanno fatti con "maiSQL" ,
da pagina 11 dell'articolo su Anand:
http://www.anandtech.com/show/2739/11
439 tps (1x SSD data / 1x HDD log)
436 tps (1x SSD data / 1x SSD log)
264 tps (8x HDD data / 2x HDD log)
225 tps (6x HDD data / 2x SSD log)
 60 tps (1x HDD data / 1x HDD log)
un ottimo hard disk SAS 15K si comporta molto
bene per uso log, manca un confronto con soluzioni
con un solo SSD (o HDD) per data e log , quindi
se hai la possibilita' di farlo .. prova :)
ciao
luca

 se hai la possibilita' di farlo .. prova :)
Proverò, non costa niente e vediamo come va.
Voglio prima aggiornare il fw del controller e dei due SSD.


 avendo tu un controller hardware probabilmente sarà meglio noop).
Ho fatto qualche prova con i dischi meccanici e la soluzione migliore
è stata proprio il cfq, con il read ahead a 4096 settori (2MiB) e nr_request
a 128 (default).
Ho provato cfq, deadline e noop con read_ahead a 0/128/2048/4096/8192.
Ora sto provando a variare il nr_requests per vedere se cambia qualcosa.
I test sono eseguiti su 5 WD RE4 1TB in RAID5 hw con LSI2108.
La scheda è in read ahead, write back su 512Mb di ram e la cache dei
dischi è abilitata.
Appena terminata questa macchina passo a fare le verifiche con gli SSD.


 è stata proprio il cfq,
Son contento: anch'io uso cfq per i dischi meccanici. :)


 se il RAID e' hardware perche' deve allineare anche LVM ?
Certo, non è affatto detto che lo si usi. :)


 Certo, non è affatto detto che lo si usi. :)
Ops la domanda mi era sfuggita.
Nel caso specifico, io uso anche LVM sul raid hw.
Rispondendo a 2fast,  è importante allineare il volume per
questione di prestazioni, perché ogni layer che aggiungi ha
una sua dimensione di blocco minimo e se l'inizio dei blocchi
non corrisponde tra tutti i layer finisce che prima o poi devi
leggere più di un blocco per far contento il layer superiore.
Anche se comunque con i vari read ahead (quello del kernel,
quello della scheda sas e quello del disco se ce l'ha) l'impatto
mi sa che è inferiore rispetto al non allineare la partizione.
Se ho detto sciocchezze correggetemi, grazie!


 leggere piů di un blocco per far contento il layer superiore.
Aggiungo che poi quei volumi lvm sono dischi per macchine
virtuali, quindi vengono poi partizionati ed eventualmente ci
si crea volumi lvm su... vedi tu quanti layer prima di arrivare
a scrivere un blocco sul disco!


 a scrivere un blocco sul disco!
e' chiaro il concetto di allineamento, domandavo sulla
necessita' di usare LVM considerando la presenza di
un controller hardware a monte, che tra l'altro gestisce
di suo i volumi logici (per non aggiungere altri livelli di
astrazione)
se e' per una questione organizzativa va bene cosi'
(o se ci sono altri motivi)
ciao
luca

 (o se ci sono altri motivi)
Non avevo dubbi che tu lo sapessi, ma come dicevo altrove
preferisco sempre scrivere "per i posteri" così chi trova le
discussioni legge informazioni complete :-)
LVM è proprio per una questione organizzativa, non posso avere
decine di partizioni immodificabili da usare come dischi per i
virtuali, mi serve LVM in modo da poter gestire liberamente lo
spazio a disposizione in caso di necessità, o semplicemente perché
un virtuale va dismesso e voglio riutilizzarne lo spazio.
Quindi la mia situazione, su questa macchina, potrebbe essere:
Dischi => Scheda SAS (RAID5) => /dev/sda
/dev/sda7 => LVM Volume Group 'Server' allineato a 256k
VG 'Server' => Logical Volume 'test' di 50Gb
LV 'test' visto come /dev/hda da un trixbox virtuale => partizioni allineate 
a 1M
/dev/hda2 del trixbox => LVM Volume Group VolGroup00
VolGroup00 => Logical Volume 'LogVol00'
Logical Volume 'LogVol00' => Mount point (finalmente!) /
Una cosa da ricordare sempre è modificare la configurazione di
LVM del server per usare solo /dev/sda (o quel che è) altrimenti
trova pure VolGroup00 e non si sa che può succedere.
In una situazione simile, se non mi serve più il trixbox mi basta
eliminare il volume e ho subito a disposizione 50Gb da usare
come voglio, anche per estendere un altro volume.
Se invece usassi le partizioni avrei un buco da 50Gb sul disco.
