Newsgroup: it.comp.os.linux.sys
Titolo: Test su raid0 e crittazione

Posto qui i risultati dei test sulle prestazioni di un raid0
crittato, come mi aveva suggerito THe_ZiPMaN.
I test sono stati effettuati su due dischi nuovi, inutilizzati: due
Seagate Barracuda SATA2 da 250GB (ST3250310AS), /dev/sda e dev/sdb.
La CPU è un core2duo@3GHz, senza processi impegnativi in corso
(occupazione 1%-5%).
Velocità di base dei dischi in perfetto accordo con quanto dichiarato
dal produttore:
| lem@GUTSYCOMP:~$ sudo dd if=/dev/sdb of=/dev/null bs=8M count=100
| 838860800 byte (839 MB) copiati, 8,23213 secondi, 102 MB/s
Sono state create sui due dischi due partizioni estese, identiche, e
al loro interno due partizioni logiche, identiche, da circa 10GB
l'una: /dev/sda5 e /dev/sdb5.
| lem@GUTSYCOMP:~$ sudo dd if=/dev/sdb5 of=/dev/null bs=8M count=100
| 838860800 byte (839 MB) copiati, 8,84334 secondi, 94,9 MB/s
Anche in seguito le prove di velocità sono state eseguite secondo il
medesimo schema:
dd if=[device da testare] of=/dev/null bs=8M count=100
Per meglio apprezzare gli effetti della pura crittazione, ho scelto
di fare a meno dei filesystem.
È stato creato un raid0 con mdadm:
| sudo mdadm --create /dev/md1 --level=0 --raid-devices=2 /dev/sda5 /dev/sdb5
Tale raid0 ha prodotto una velocità di 190 MB/s (esattamente quanto
ci si sarebbe aspettato).
Il raid0 è stato crittato AES 256 bit:
| sudo cryptsetup --verbose -y -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/md1
| sudo cryptsetup luksOpen /dev/md1 raid0test
e la velocità è purtroppo crollata a 100 MB/s.
Si è poi scelta una strada diversa: prima sono state crittate le due
partizioni fisiche, indipendentemente l'una dall'altra. Ciascuna ha
prodotto una velocità di 78 MB/s.
Le due partizioni crittate sono state quindi messe in raid0, e
quest'ultimo ha prodotto una velocità di 160 MB/s. 
La soluzione di crittare le partizioni fisiche e di metterle
successivamente in raid0 appare premiante dal punto di vista della
velocità, a patto di avere sufficiente potenza CPU.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 velocità, a patto di avere sufficiente potenza CPU.
E si spiega perche`?
E un limite "concettuale" oppure e` un discorso
implementativo?
bye,
-- 
piergiorgio

 implementativo?
Guarda che fra noi due chi se ne intende di 'ste robe sei sicuramente
tu: dimmelo tu! ;)


 tu: dimmelo tu! ;)
Direi che la spiegazioni che hai dato sopra calza.
Due CPU, due letture, due enc/dec, un mix,
contro due letture, un mix, un enc/dec.
Sospetto che la crittograffazione giri in kernel
thread, se e` cosi` puo` essere instanziata due volte
su due CPU.
Sarebbe da provare, se hai tempo, con un single core
(dovrebbe essere sufficiente un paramentro al boot,
credo, per usare un solo core).
In teoria dovresti avere le stesse prestazioni nei
due casi.
Thanks!
bye,
-- 
piergiorgio

 due casi.
Sorpresa: no. 
Con una sola CPU, ciascuna partizione non crittata mantiene
naturalmente la sua velocità (95 MB/s). Crittata, scende a 50 MB/s (e
satura completamente la CPU: 100% di carico).
In raid0, le prestazioni ancora una volta raddoppiano: 102 MB/s (e
naturalmente si arriva anche qui al 100% di carico).
Un po' diverso è il caso delle partizioni prima messe in raid0 e poi
crittate: stavolta non si raddoppia più, ma ci si arriva comunque
vicino (molto più che con due cpu, in proporzione).
Riepilogando, in MB/s:
--------------------------+-----------+----------+
                          |   1cpu    |   2cpu   |
--------------------------+-----------+----------+                
disco                     |    102    |    102   |
partizione logica         |     95    |     95   |
raid0                     |    190    |    190   |
partizione crittata       |     50    |     78   |
raid0 poi crittato        |     91    |    100   |
part. critt. poi in raid0 |    102    |    160   |
--------------------------+-----------+----------+
Direi: con una sola CPU la potenza di calcolo scarseggia, e quindi il
beneficio dato dal miglior parallelismo nella (de)crittazione non si
avverte così tanto (91 vs 102). Con due CPU il vantaggio è invece
evidente (100 vs 160).
Mi sembra anche che, se prima si fa un raid0 e poi lo si critta,
aumentare il numero di cpu non serva a granché (91 vs 100): come dire
che il parallelismo interno che il software è in grado di realizzare,
quando la decrittazione è seriale, è minimo.
Invece non capisco bene come mai, con una sola CPU, ci sia così tanta
differenza fra la partizione singola crittata da un lato, e i raid0
dall'altro (50 vs 91 e 102), se in tutti e tre i casi il carico CPU
viene segnalato al 100%.
BTW: a parte i dettagli, per ogni dispositivo crittato ho una coppia
di processi (kcryptd e kcryptd_io, il primo pesa 3 o 4 volte il
secondo): questo a prescindere dal numero di CPU.


 secondo): questo a prescindere dal numero di CPU.
Hai controllato con "top"? Non ti fidare troppo...
bye,
-- 
piergiorgio

 Infatti hai 91 vs 102, siamo "solo" al 10% in meno.
Ah, avevo frainteso!
Grazie per tutti i tuoi commenti.


 Grazie per tutti i tuoi commenti.
Di niente, ho trovato il tuo test interessante
ed informativo.
E` sempre utile prendersi il tempo per fare
certe prove e valutazioni.
Grazie a te.
bye,
-- 
piergiorgio

 crittato, come mi aveva suggerito THe_ZiPMaN.
<snip>
Ottimo lavoro, grazie.
Stefano
P.s. a breve mi arriverà un server con due xeon quad-core e, come mia
abitudine, prima di metterlo in produzione, lo sottoporro a torture varie
per validare l'hw. Ti viene in mente qualche altra prova da fare
sull'argomento? 

 sull'argomento? 
Fai dei test con iozone. 
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 velocità, a patto di avere sufficiente potenza CPU.
L'esatto opposto di quanto mi aspettassi dalla teoria.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 L'esatto opposto di quanto mi aspettassi dalla teoria.
Quale teoria, scusa?
La spiegazione teorica che ha dato calza perfettamente.
bye,
-- 
piergiorgio

 Quale teoria, scusa?
La teoria di cui si è discusso la scorsa settimana e che era il motivo per 
cui ha condotto i test.


 per cui ha condotto i test.
Ho trovato, mi era sfuggito il thread.
Credo, se ho capito bene, che la differenza con
l'altra teoria sia il fatto che ha due CPU per
due dischi, quindi conviene comunque avere il
piu` a lungo possibile due processamenti paralleli.
Infatti, con una sola CPU, le cose cambiano radicalmente.
bye,
-- 
piergiorgio

 sull'argomento?
Avrai tanta tanta cpu, e immagino ti interessino test che possano
produrre anche risultati verificabili. Per restare in tema, e per
farla semplice, potresti provare a vedere che succede usando dd da un
raid0 fatto con partizioni crittate verso un altro raid0 (su dischi
diversi) fatto similmente, invece che verso /dev/null. Così potresti
anche controllare l'integrità della copia rispetto all'originale,
equindi che non ci siano stati errori in decrittazione/crittazione.
Vuoi proprio il massimo stress per i processori? Potresti provare con
otto grossi ramdisk crittati, messi in raid0. ;)
In generale credo che sarebbero molto interessanti anche prove
specifiche sulle prestazioni ottenibili con raid costruiti in certi
modi e con certe opzioni, con sopra questo o quel filesystem[*],
avendo come punto di riferimento file di certe dimensioni o
applicazioni di un certo tipo. Ma questo non te lo chiederei mai: si
entrerebbe troppo nello specifico. Tirando in ballo i filesystem,
come già suggerito, un bench sintetico come iozone andrebbe comunque
benone.
[*] Penso per esempio al tail packing di reiserfs, o al fatto che
cogli ext*fs (e cogli altri?) è opportuno che nel raid0 i gruppi di
blocchi inizino su dischi diversi, e all'impatto che queste cose
possono avere.


 Infatti, con una sola CPU, le cose cambiano radicalmente.
Sarebbe anche interessante vedere il comportamento con il raid1. Lem, già 
che ci sei, non puoi provare?


 che ci sei, non puoi provare?
Oggi non posso, domani provo.
Però, secondo me, col raid1 hai assolutamente ragione: facendo due
partizioni crittate e poi mettendole in raid1 si ottiene solo di
(de)crittare due volte gli stessi identici byte. Inutilità assoluta,
mi sembra.
Di più: come mi dicevi nell'altro filone, la sicurezza è compromessa.
Io non conosco nulla di algoritmi crittografici, ma se arrivo a
sapere che due partizioni crittate con diverse chiavi/algoritmi sono
in raid1, e magari arrivo a individuare alcuni (molti) settori
(a1,a2,b1,b2...) che sono stati scritti, allora costruisco un
sistema:
a1 = k(a); a2 = h(a)
b1 = k(b); b2 = h(b)
c1 = k(c), c2 = h(c)
...
con h(),k(),a,b,c... incognite.
Insomma, a naso mi pare che questo possa aiutare molto a trovare le
"funzioni di crittazione" k() e h().


 sapere che due partizioni crittate con diverse chiavi/algoritmi sono
In raid1 devi usare, ovviamente, la stessa chiave
per le due partizioni sottostanti, altrimenti
_sicuramente_ indebolisci la crittograffazione.
Riguardo le prestazioni.
In lettura non dovrebbe essere diverso dal raid0, in
quanto si spera legga i blocchi alternativamente dai
due device, quindi due decrypt thread lavorerebbero
su dati diversi, in parallelo (con 2 CPU).
L'unico dubbio potrebbe essere sulla necessita` del
decrypt di avere _tutti_ i dati, anche quelli che non
sono richiesti, per poter funzionare.
In scrittura, sempre raid1, sarebbe invece bello
poter fare il crypt _prima_ del raid.
D'altronde non si puo` avere tutto nella vita... :-)
bye,
-- 
piergiorgio

 su dati diversi, in parallelo (con 2 CPU).
Sì, però per questo non posso usare dd. Con un raid1 le prestazioni
di dd anche in lettura, non solo in scrittura, sono identiche a
quelle con un disco solo. Immagino che ciò sia dovuto al modo con cui
dd opera, strettamente sequenziale. Devo introdurre un filesystem e
andare di cp, allora.
Avete preferenze sul filesystem e sul tipo di file (pochi k, molti
mega...)? 


 mega...)? 
Prima risolverei la questione raid1... :-)
bye,
-- 
piergiorgio

 dmsetup - che non ho mai usato, il che potrebbe significare disastri. ;)
Oppure critti un solo device e poi lo copi sull'alltro prima di metterli in 
RAID.


 tra i due device.
Ho ricontrollato, ma confermo. Con 2 cpu, raid1 in chiaro, 100 MB/s:
come disco singolo. Crittando il raid1, si scende a 80 MB/s. Questo
senza i filesystem, appunto.
Ho quindi messo un filesystem sul raid1 crittato, e l'ho montato:
mkreiserfs -s 32749 /dev/mapper/raid1
mount /dev/mapper/raid1 /mnt
Copiando con dd *sul* filesystem:
dd if=/dev/zero of=/mnt/file bs=8M count=200
ottengo stranamente valori variabili fra 135 e 90 MB/s. Non è la
cache del disco: ogni volta faccio
sync && echo 1 > /proc/sys/vm/drop_caches
per neutralizzarla. Questo è proprio il filesystem asincrono:
l'operazione appare finita prima di esserlo, si vede a occhio.
Va beh, come non fatto.
Copiando con dd dal filesystem i risultati sono naturalmente più
stabili, pochi MB/s di tolleranza:
dd if=/mnt/file of=/dev/null bs=8M count=200
1677721600 byte (1,7 GB) copiati, 23,3205 secondi, 71,9 MB/s
Ho confrontato con analoga operazione fatta da altra partizione
crittata su uno dei due dischi usati per il raid. Il raid1 perde
contro una partizione singola:
dd if=/media/mount/file of=/dev/null bs=8M count=100
838860800 byte (839 MB) copiati, 8,92076 secondi, 94,0 MB/s
Ho poi cercato di creare la possibilità di accessi simultanei al
filesystem, e infatti le differenze ci sono. Usando un file da 800MB:
time cp /mnt/file /dev/null
real	0m11.508s
user	0m0.016s
sys	0m0.426s
time (cp /mnt/file /dev/null & cp /mnt/file /dev/null)
real	0m14.262s
user	0m0.046s
sys	0m0.772s
nel secondo caso il tempo impiegato per due file è solo di poco
superiore a quello impiegato per un file solo.
Ho confrontato con analoghe operazioni fatte da altra partizione
crittata su uno dei due dischi usati per il raid:
time cp /media/mount/file /dev/null
real	0m8.995s
user	0m0.016s
sys	0m0.401s
time (cp /media/mount/file /dev/null & cp /media/mount/file /dev/null)
real	0m17.090s
user	0m0.026s
sys	0m0.314s
Il raid1 perde nettamente (!!!), ancora, col singolo file,
ciononostante recupera abbondantemente e vince a mani basse in caso
di accessi simultanei.
Poi ho copiato la mia directory /var, con tutto il suo contenuto di
12526 oggetti per 421,3 MB totali, sul raid1 crittato. Da lì l'ho
copiata su un filesystem virtuale:
time cp -r /mnt/var/* /dev/shm/var
real	0m8.358s
user	0m0.036s
sys	0m0.620s
Ho confrontato il tutto con analoga operazione fatta da altra
partizione crittata su uno dei due dischi usati per il raid:
time cp -r /media/mount/var/* /dev/shm/var
real	0m6.421s
user	0m0.027s
sys	0m0.641s
Anche qui il raid1 perde clamorosamente in lettura, si vede che cp
non parallelizza mica tanto! Più vado avanti, e meno capisco 'sto
raid1 che fa.
Comunque in generale direi: lo strato di software che gestisce il
raid1 è *parecchio* penalizzante. Solo in caso di veri accessi
simultanei è davvero premiante, altrimenti è una mazzata nei gioielli
di famiglia. :(
Domani il resto, colla curiosità delle due partizioni prima crittate
e poi messe in raid1.


 tra i due device.
Ho ricontrollato, ma confermo. Con 2 cpu, raid1 in chiaro, 100 MB/s:






















 Va beh, come non fatto.
Potrebbe essere anche la gestione dei file sparse.


Lem Novantotto wrote:
[...]
Ho dato un'occhiata in giro riguardo le prestazioni
in lettura del raid1.
Sulla sezione "vantaggi", del raid1 di Linux, si dice
che "e` possibile" avere prestazioni doppie.
Pero` in una mailing list (del kernel, credo) viene
anche detto che cio` e` possibile solo in caso di
thread multipli, che leggono differenti "stream".
Sembrerebbe, questo ultimo punto, confermare le tue
misure.
Resta il mio personale dubbio sul fatto che l'attuale
implementazione non sia ottimale, dato che non ho
trovato nessuna giustificazione al riguardo.
bye,
-- 
piergiorgio

 e poi messe in raid1.
Ecco qui: due partizioni identiche, crittate identicamente (la
seconda ottenuta copiando la prima con dd), poi messe in raid1.
dd if=/dev/md0 of=/dev/null bs=8M count=200
1677721600 byte (1,7 GB) copiati, 18,7039 secondi, 89,7 MB/s
Creato filesystem, e montato:
mkreiserfs -s 32749 /dev/md0
mount /dev/md0 /mnt
Copia con dd di un file:
dd if=/mnt/file of=/dev/null bs=8M count=200
1677721600 byte (1,7 GB) copiati, 18,0188 secondi, 93,1 MB/s
Copia con cp di un file (ora di 800 MB):
time cp /mnt/file /dev/null
real	0m11.316s
user	0m0.016s
sys	0m0.418s
Copie simultanee:
time (cp /mnt/file /dev/null & cp /mnt/file /dev/null)
real	0m14.026s
user	0m0.052s
sys	0m0.768s
Poi ho copiato la mia directory /var, con tutto il suo contenuto di
12526 oggetti per 421,3 MB totali, sul raid1. Da lì l'ho
copiata su un filesystem virtuale:
time cp -r /mnt/var/* /dev/shm/var
real	0m7.773s
user	0m0.026s
sys	0m0.651s
Ora la tabella riepilogativa sul raid1, a confronto con una
partizione singola. Asteriscati i valori migliori:
--------------+--------------+-------------------------+---------------
              | raid1 critt. | 2 part. critt. in raid1 | 1 part. critt.     
--------------+--------------+-------------------------+---------------             
dd dal device |   80 MB/s    |           90 MB/s       |    *92* MB/s
              |              |                         |  
dd dal fs     |   72 MB/s    |           93 MB/s       |    *94* MB/s
              |              |                         |
cp dal fs     |   11.5 s     |           11.3 s        |     *9* s
file 800MB    |              |                         |
              |              |                         |
cp simultanei |   14.2 s     |          *14.0* s       |      17 s
dal fs        |              |                         |
              |              |                         |
cp -r         |    8.3 s     |            7.7 s        |     *6.4* s
--------------+--------------+-------------------------+----------------
Sorprendentemente la soluzione singola vince sempre nettamente,
tranne quando ci siano davvero accessi concorrenti al filesystem.
Allora i raid stravincono[*], ma hanno prestazioni analoghe. E, fra i
due, almeno in quete semplici situazioni esaminate, ogni volta se la
cava meglio il raid1 che critta due volte. Non me lo sarei mai
aspettato!
[*] Usando due file distinti e identici, ciascuno da 800MB, con
time (cp /mnt/file /dev/null & cp /mnt/file2 /dev/null)
le prestazioni dei raid si migliorando ancora, arrivando a 12 secondi
circa, proprio il tempo impiegato per copiare una sola volta un solo
file: ma time mi dà valori errati (sui 9 secondi: esce prima che il
disco smetta di scrivere), devo cronometrare io.


 trovato nessuna giustificazione al riguardo.
Mi verrebbe quasi la voglia di provare il fake-raid-controller della
motherboard: alla fine è sempre software, ma forse è implementato
meglio...


 disco smetta di scrivere
Errata corrige: di leggere.


 meglio...
Ormai non sono molte le MB server che montano un fake raid. La diff di costo 
ormai è 0.


 La diff di costo ormai è 0.
Ma va'? Mi sembrava che dei buoni controller RAID costassero ancora
centinaia di dollari.


 centinaia di dollari.
Robe così:
http://store.3ware.com/?category=10&subcategory=8&productid=9650SE-4LPML


 centinaia di dollari.
Se cerchi qualcosa che faccia raid5/6 e con cache a bordo sì.
Ma per RAID0/1 senza cache costano tanto quando i controller scsi normali


 | sudo cryptsetup luksOpen /dev/md1 raid0test
Non è che potreti segnalarmi un guida comleta a dm-crypt/crypsetup/luks,
in cui siano anche trattate le varie modalità operative di AES
(cbc-plain, cbc-essiv, lrw-benbi, xts-plain ...)?
In alternativa, dove hai reperito la documentazione per imparare ad
usare dm-crypt?
Grazie.
-- 
Lurkos