Newsgroup: it.comp.os.linux.sys
Titolo: Ssd raid1

Ciao
Qualcuno usa degli ssd in raid 1?
Da quel che so, tutte le memorie flash hanno un numero limitato di scritture, metterne due in raid significherebbe avere lo stesso numero di scritture su ambo i dischi e quindi potenzialmente la stessa probabilità di rottura nello stesso momento 
 
Come vi tutelate da ciò?


Hai le seguenti possibilita`:
 
1) Usi 2 SSD di due marche diverse. Completamente
diverse, cioe` non uno che sia la sottomarca del
altro o che usi gli stessi componenti. Di solito
hanno durate differenti.
 
2) Prendi 3 SSD, due li usi in RAID-1 subito.
Dopo un po' di tempo rimpiazzi uno dei due
con il terzo. Dopo un altro po' di tempo,
rimpiazzi il piu` vecchio con quello rimosso.
E cosi` via.
 
Prima o poi uno si rompe, ma difficilmente due
in contemporanea.
Quando si rompe uno, compri uno nuovo e continui
il giochetto.
 
Il tutto puo` anche essere automatizzato e se
usi "--replace" (con "mdadm") non devi neanche
fare l'upgrade / downgrade dell'array.
 
Ovviamente, la SSD rimossa deve passare per un
ATA secure erase, che azzera tutto, incluso lo
stato trim.
 
bye,
 
-- 
 
piergiorgio

On 2016-04-14 18:35, Piergiorgio Sartor wrote:
[...]
Ovviamente, si puo` usare anche una combinazione di
1) e 2), cioe` 3 SSD di marche diverse a rotazione.
 
bye,
 
-- 
 
piergiorgio

 stato trim.
 
Perchè? Tanto se è rotta la butto via.

 fino a 999 posso stare tranquillo ?
 
Naturalmente no. Sono tutte durate stimate, anche perchè per fare un 
test approfondito ci vogliono anni di letture e scritture continue, e 
naturalmente su un S.O. in uso hai troppe variabili da considerare per 
determinare esattamente quante scritture sono avvenute.
 
Bye.
 
 

 Perchè? Tanto se è rotta la butto via.
 
  In linea di principio, se il guasto è riparabile (ad es., cambiando
l'elettronica di controllo proveniente da un disco uguale, oppure
spostando le celle NAND in un lettore da laboratorio), i dati sono
recuperabili.  Se i dati salvati sono importanti e riservati, fare
quello che dice Piergiorgio Sartor è una buona misura da prendere per
cautelarsi dai casi più estremi.  Un'altra strategia è di usare sempre
partizioni criptate sui dischi, così quelli rotti li puoi buttare via
senza darti pensiero di quello che c'era scritto sopra.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 scontata sin dall'inizio dell'esercizio del RAID.
 
Se invece facessi RAID-6, che lo preferisco anni luce?
Mi costa esattamente il triplo, ma il problema persisterebbe ?
Anche in un RAID-6 le scritture avvengono in stessa quantità sullo stesso numero di dischi ?
 
Un RAID-6 a 3 o 4 dischi protegge di più (sempre parlando di SSD) rispetto un RAID-1 dove è quasi certa la rottura di due dischi in contemporanea (quasi certa o altamente probabile, proprio perchè si tratta di SSD)

 (quasi certa o altamente probabile, proprio perchè si tratta di SSD)
 
se prescindi dall'acquisto di ssd dello stessa marca/lotto/modello si, un R6 
è più sicuro (sempre con spare :) )
A me ha salvato il posteriore (complice anche il buon funzionamento della 
san) con una partita di hd difettosi gentilmente inseriti dalla fujitsu 
nella san
Le prestazioni però son quelle che sono
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 Perchè? Tanto se è rotta la butto via.
 
Nel caso della rotazione con 3.
Quella che rimpiazzi non e` rotta, e` in
parking ed e` meglio azzerarla.
 
bye,
 
-- 
 
piergiorgio

 Un RAID-6 a 3 o 4 dischi protegge di più (sempre parlando di SSD) rispetto un RAID-1 dove è quasi certa la rottura di due dischi in contemporanea (quasi certa o altamente probabile, proprio perchè si tratta di SSD)
 
Quello che i data center usano sono RAID-1
con 3 dischi. Proprio per gli IOPS.
 
Hai migliori prestazioni e la rottura di
due dischi non e` certa, se usi le giuste
precauzioni del caso.
Ovvero e` certa anche per HDD rust.
 
bye,
 
-- 
 
piergiorgio

 si rompono in lettura.
 
Leggendo il thread mi sono ricordato di avere nel segnalibri questo
articolo:
http://www.miamammausalinux.org/2016/03/google-e-laffidabilita-della-tecnologia-ssd/
 
che credo potrebbe interessarvi, se ovviamente non lo avete gia` letto.
 
 
 
 

 di uno HW.
 
Solitamente i raid hw sono più performanti, grazie
alle cache. Leggevo online che sostanzialmente
la cache riesce a convertire scritture random in
sequenziali (scrivendo i dati tutti in una volta)
migliorando quindi le performance.
 

 Non conviene, se servono IOPS, e` un suicidio.
 
Nel caso specifico devo sostituire in server mysql (22GB l'intera base dati) e dischi SATA con un server a 64GB e, forse, SSD (ma credo di optare per il più classico SAS 15k). Potrei fare anche un RAID-1 a 35 dischi, avrei performance comunque superiori di qualche ordine di grandezza, volendo tutta la base di dati sta in RAM, oltre che su SSD.

 
 
Da quello che leggo in giro (non posso, pero`
confermare di persona) per applicazioni DB,
con SSD, si usano 3 SSD in RAID-1 (3 per i
motivi precedentemente esposti).
 
Al massimo, usando "md", si puo` provare
un RAID-10 (non 1+0 o 0+1, ma 10 nativo).
 
bye,
 
-- 
 
piergiorgio

 migliorando quindi le performance.
 
La cache la hai anche nel RAID SW, solo che usa
la memoria del computer, invece di una separata.
E fa esattamente la stessa cosa, cioe` cerca di
convertire operazioni (scritture) random in
sequenziali.
 
Tempo fa vi erano vari test in giro.
Puo` essere che oggi le cose siano diverse, ma
all'epoco isultava che il RAID-5 SW e` piu veloce
di quello HW, ovviamente, dato che, di solito, si
ha una CPU di gran lunga piu` potente.
Il RAID-6 SW, che e` ottimizzato per il calcolo
di Q, ma niente piu`, era piu` o meno uguale a
quello HW.
 
Tanto per capirci, un controller SAS LSI2308 ha,
come CPU, un PPC a 800MHz.
 
bye,
 
-- 
 
piergiorgio

 ha una CPU di gran lunga piu` potente.
 
Mi ero fatto una NAS (debian, mdadm e sei dischi in raid 5).
 
Tutto bello, il t/r sequenziale superava i 500MB/s, ovviamente a dischi 
vuoti, ma mdadm spremeva un core duo a 3.5GHz come un limone.
 
Adesso ho trovato un "controllerino" M5015 IBM (in pratica il 2960-8i, 
che usato su ebay si trova a due soldi con tutta la batteria) ho messo 
altri due dischi, il raid vola e la cpu è fresca come una rosa. E' vero 
che la cpu principale è più potente, ma il controller è ottimizzato e fa 
solo quello.
 
Di mdadm mi piaceva che decidevo tutto io, adesso lascio fare e vivo 
sereno. :)
 
raid di saluti
 

 sereno. :)
 
Vi e` anche un altro punto.
 
Con "mdadm" hai cose come bitmap, error log,
proactive replacement ed altro.
 
Solo controller very very very high end hanno
tutte quelle feature.
 
bye,
 
-- 
 
piergiorgio

 sereno. :)
 
Tra l'altro, dimenticavo, con il RAID SW
e` possibile fare anche... porcate... tipo
RAID tra dischi e RAM o tra SATA e USB o
tra SATA e iSCSI...
 
Per es., e` possibile fare un RAID-1 con un
disco "lento" ed uno "veloce" (anche RAM),
marcando il "lento" come write-mostly.
 
In questa situazione, le letture vengono
passate, per quanto possibile, prima al
disco "veloce".
 
In caso di poche scritture e molte letture
si ottiene un sistema affidabile e veloce.
 
bye,
 
-- 
 
piergiorgio

 con un RAID-5.
 
Quando scriveva a 500MB/s, top mi indicava il 140% di cpu (due core al 70%).
 
uso di saluti
 

 70%).
 
Quanti secoli fa? :-)
 
Io, con 5 dischi, 400~500MB/s, vedo scarso
un 25% CPU, avendo il massimo possibile della
cache (quindi poca attesa I/O).
 
bye,
 
-- 
 
piergiorgio

 sereno. :)
 
Anche io vivevo sereno, prima di ritrovarmi una pertica sul per il cu.lo con due dischi a puttane senza che la controller si sia accorta di nulla e quasi 2TB di dati andati persi. (raid 10 con 6 dischi da 600GB)
 
No, non è causuale. Altro disco rotto su altro server, la controller dice "tutto ok" e termina anche il check consistency positivamente, ma il disco è rotto (errori i/o visibili direttamente da Debian). Stessa controller.

 sequenziali.
 
Lo fa di suo il kernel o va abilitato in qualche modo ?

 tra SATA e iSCSI...
 
Avete dimenticato *IL* vantaggio fondamentale:
spostare dischi da un server all'altro senza batter ciglio.
 
Nessun controller RAID è compatibile con altri, spesso (direi sempre) sono incompatibili anche all'interno dello stesso brand.
 
con raid sw puoi cambiare un intero server semplicemente spostando i dischi sul server nuovo. con il raid hw devi migrare tutti i dati con tutto ciò che ne consegue (down, disservizi, fermo macchine, ....)

 spostare dischi da un server all'altro senza batter ciglio.
 
Indubbiamente, era talmente scontato che non
mi era neanche venuto in mente...
 
bye,
 
-- 
 
piergiorgio

 Lo fa di suo il kernel o va abilitato in qualche modo ?
 
Lo fa il driver "md".
 
Quello che puoi configurare e` quanta RAM.
Dovrebbe essere in:
 
/sys/class/block/mdX/md/stripe_cache_size
 
Dove la memoria usata e`: 4K*n_dischi*valore
 
"valore" e` il valore in sysfs, ovviamente.
 
Quindi, attenzione con RAID da 20 dischi...
 
C'e` anche da dire che Neil Brown (l'autore
di "md") non e` molto contento di come sia
l'algoritmo della cache.
Infatti, non e` detto che piu` cache si usi
piu` veloce vada il tutto.
Bisogna fare qualche test. Per es., io ho un
sistema dove 8192 da il massimo delle prestazioni.
 
bye,
 
-- 
 
piergiorgio

 mi era neanche venuto in mente...
 
io ad esempio devo migrare preventivamente alcuni server con PERC H200 a qualcosa di più recente e non so come fare.
 
La H200 non è supportata come partenza upgrade dalle recenti H730 e nemmeno da quelle subito prima come la H710. Devo, teoricamente, upgradare da H700, poi da H700 a H710 e poi H730
 
c'è da dire che la cosa mi puzza non poco, la H710 importa da H700, che è la stessa famiglia della H200, ma non importa (stando al manuale) da H200.
 
Mah. Resta comunque il fatto che non so come fare, se non facendo 3 importazioni (che mi fanno sempre tremare le gambe, il passo falso è facile da fare e si perde tutto)

 cache (quindi poca attesa I/O).
 
Intendi dire che, con top, vedi mdadm che ti impegna una sola cpu 
(quindi 100%), e avendo quattro core correttamente scrivi di avere un 
quarto della cpu impegnata?
 
La macchina su cui girava da me era un core duo e il raid 5 aveva un 
disco in più. Se la tua cpu fosse un i5 con quattro core, quindi più 
efficiente del core duo, i conti tornerebbero.
 
Ovviamente questo solo in fase di scrittura, quando viene calcolata la 
parità. In lettura a parità di t/r l'impegno è assai minore.
 
saluti secolari
 

 No, non è causuale...
 
Controller di merda, che roba era?
 
saluti casuali

 Controller di merda, che roba era?
 
PERC H200

 PERC H200
 
So che non godono di gran reputazione. Io in ogni caso lo stato dei 
dischi lo controllo *anche* con smartctl o simili. Mai fidarsi :)
 
saluti e controlli
 

5 dischi in raid6? 
A quanti dischi vi siete spinti su un raid6 software? 
 
Sono fortemente tentato di usarlo in tutti i sistemi che non richiedono baremetal (xenserver o proxmox ad esempio)  ma da cui parlo da una Debian liscia (tipo tutti i miei database) 
 
Visto che sono fuori dal giro da anni, volume raid singolo e lvm sopra, oppure volumi raid multipli? Preferisco la prima soluzione, molto più flessibile. 
Non ho mai trovato vantaggi a fare volumi multipli per il raid, sono svantaggi nel caso dovessi estendere o cambiare dischi

 quarto della cpu impegnata?
 
25% di un core. Ed e` anche tanto.
 
Su di un Haswell non vedo neanche quello... :-)
 
bye,
 
-- 
 
piergiorgio

 Non ho mai trovato vantaggi a fare volumi multipli per il raid, sono svantaggi nel caso dovessi estendere o cambiare dischi
 
Io avevo un problema simile. Mi serviva LVM,
RAID e LUKS.
 
Ho provato tutte le combinazioni, quella che
alla fine mi pare (per me medesimo) sia il
miglior compromesso e` RAID->LVM->LUKS.
 
Cioe` LUKS su LVM su RAID su HDD.
 
bye,
 
-- 
 
piergiorgio

 e` MT) a... boh..., 2.8GHz forse.
 
A questo proposito...
 
Con 10 dischi da 200MB/sec (non SSD) si
arriva a max 2GB/sec di transfer rate
possibile (per solo i dati 1.6GB/sec).
Di conseguenza, avendo una capacita` da
10GB/sec per il calcolo delle parita`,
significa che si usera` il 20% della CPU.
 
Il che mi torna con quello che vedo
con top.
 
Da notare, che la CPU usa AVX per il
calcolo delle parita`.
Con SSE solamente si va piu` lenti.
 
bye,
 
-- 
 
piergiorgio

 Da notare, che la CPU usa AVX per il calcolo delle parita`.
 
Allora è questo il motivo della differenza di prestazioni riscontrata da me.
 
parità di saluti
 


Queste sono le prestazioni su AMD Opteron(tm)
Processor 3350 HE a 2.8GHz:
 
[ ...] raid6: sse2x1   gen()  5832 MB/s
[ ...] raid6: sse2x1   xor()  3925 MB/s
[ ...] raid6: sse2x2   gen()  9195 MB/s
[ ...] raid6: sse2x2   xor()  6400 MB/s
[ ...] raid6: sse2x4   gen() 11027 MB/s
[ ...] raid6: sse2x4   xor()  5822 MB/s
[ ...] raid6: using algorithm sse2x4 gen() 11027 MB/s
[ ...] raid6: .... xor() 5822 MB/s, rmw enabled
[ ...] raid6: using ssse3x2 recovery algorithm
[ ...] async_tx: api initialized (async)
[ ...] xor: automatically using best checksumming function:
[ ...]    avx       :  4260.000 MB/sec
 
Non c'e` AVX (che la CPU ha), ma sse2x4 fa
10GB/sec...
AVX e` usato per l'XOR, non so perche`.
 
bye,
 
-- 
 
piergiorgio

 miglior compromesso e` RAID->LVM->LUKS.
 
Quindi tu fai un singolo volume raid, sopra il
quale poi ci piazzi LVM....

 Con SSE solamente si va piu` lenti.
 
Tutto ciò per me è arabo.
Traducete per cortesia. Io ho tutti server Xeon, dai 5400 ai più recenti E5-2600

 Traducete per cortesia. Io ho tutti server Xeon, dai 5400 ai più recenti E5-2600
 
Il drive RAID-456 fa un test di varie
possibili implementazioni per il
calcolo delle parita` P e Q (nel caso
del RAID-6).
 
Si va dal semplice codice C, si passa
per codice ottimizzato con MMX, poi
SSE varie e AVX.
MMX, SSE e AVX sono le istruzioni, di
varie generazioni, vettoriali.
Cioe` prendono un vettore (di byte) e
fanno qualcosa. Quindi hanno un elevato
livello di parallelismo.
 
Ora, come scrivevo sopra, il driver fa
un test e vede quale delle diverse
possibili implementazioni va piu` veloce
ed usa quella.
 
Come ho riportato nell'altro post, con
SSE (e non AVX) si raggiungono circa
10GB/sec di capacita` di "processamento".
Per un core, sempre.
 
La cosa piu` semplice da fare e`:
 
insmod raid456
dmesg
 
Dovrebbe riportare il test e le prestazioni.
 
L'unica cosa di cui potrei avere dubbi,
perche` in passato e` successo, e` che il
risultato sia *pessimistico*, in quanto
fatto con il clock minimo e non massimo.
 
In generale, ti conviene sempre fare delle
prove con una macchina di test.
 
Il motivo e` che vi sono diversi parametri,
come il chunk size, che possono far variare
le prestazioni in maniera notevole.
Il default (chunk size) di 512K viene considerato,
da qualcuno, eccessivo, e viene consigliato
un valore piu` basso, tipo 64k o 8k.
 
bye,
 
-- 
 
piergiorgio

 Dovrebbe riportare il test e le prestazioni.
 
Il test lo fa solo con raid configurato o fa stime in base alla CPU? 
Perchè nel mio computer non da segni di vita:
 
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.896289] async_tx: api initialized (async)
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900889] md: raid6 personality registered for level 6
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900890] md: raid5 personality registered for level 5
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900891] md: raid4 personality registered for level 4
 
ma non ho un raid....
 
Comunque sia, entrando nel dettaglio, devo sostituire 2 server database, attualmente con 20GB di database (cadauno), 16GB RAM e 1 processore quadcore. RAID-1 (PERC H200) con 2 dischi SATA 7200
 
Il nuovo server sarà biprocessore esa, 64GB di RAM e RAID-? a 3 o più dischi SAS 15k
 
Dal punto di vista prettamente hardware, il nuovo server è più potente dei due precedenti messi insieme, questo mi permette di accorpare del materiale, con 1 server ne rimpiazzo e ne libero ben 2.
 
Non ho la più pallida idea di quale RAID attivare. Ho la possibilità di usare una PERC H730 con BBU e 1GB di cache, o di usare un RAID software.
Posso usare SAS o SSD (ordinandoli) ma ciò che non posso fare (per tempo, voglia, fornitori, possibilità economici, logistica, etc etc) è garantire dischi differenti in termini di vendor o simili. Se ordino 3 dischi, quasi certamente mi arrivano dallo stesso lotto. Prendere o lasciare.
 
Cosa suggerite di fare, considerata l'esigua mole di dati? Volendo TUTTI i database di ambo i server potrebbero stare interamente in RAM lasciandole libera buona parte per il resto del sistema (20GB+20GB = 40GB circa di database su un server con 64GB di RAM)

 [ ...] raid6: using algorithm sse2x4 gen() 11027 MB/s
 
Boh, mi sa che non ci siamo. In questo momento non ho sottomano la NAS, 
ma la debian del portatilino mi fornisce:
[  120.697484] raid6: sse2x1   gen()  2791 MB/s
[  120.765475] raid6: sse2x1   xor()  2930 MB/s
[  120.833486] raid6: sse2x2   gen()  4723 MB/s
[  120.901483] raid6: sse2x2   xor()  4994 MB/s
[  120.969491] raid6: sse2x4   gen()  5250 MB/s
[  121.037496] raid6: sse2x4   xor()  2953 MB/s
[  121.037497] raid6: using algorithm sse2x4 gen() 5250 MB/s
[  121.037499] raid6: .... xor() 2953 MB/s, rmw enabled
 
Ma col cavolo che farebbe 5GB/s! E' un "AMD Phenom(tm) II N640 Dual-Core 
Processor" che dovrebbe valere meno della metà del core duo di cui ai 
precedenti msg.
 
saluti puramente teorici
 

 
 
 
-- 
 
piergiorgio

 Cosa suggerite di fare, considerata l'esigua mole di dati? Volendo TUTTI i database di ambo i server potrebbero stare interamente in RAM lasciandole libera buona parte per il resto del sistema (20GB+20GB = 40GB circa di database su un server con 64GB di RAM)
 
Riguardo i dischi, come gia` scritto, se hai
la stessa marca puoi ruotarli per far si che
il tempo di funzionamento (o le scritture)
siano diverse tra loro.
 
Per lo storage userei SSD in RAID-1 (2+1,
cioe` 3 in totale).
 
Hai problemi di costi, per il PERC H370?
Detto altrimenti, hai delle remore per l'uso
di tale controller?
Scrivevi di portabilita` in caso di guasti.
Hai altri pensieri?
 
Se non hai queste remore, prendi il PERC.
 
Altrimenti, se devi ottimizzare costi od
altro, potrebbe essere meglio il RAID SW.
 
bye,
 
-- 
 
piergiorgio

 altro, potrebbe essere meglio il RAID SW.
 
In *questo* caso non è un problema di costi. Ho già ordinato
il server, ho già ordinato la controller, abbiamo già
pagato tutto. Quindi ho già tutto a disposizione (deve solo arrivare)
 
Non so se usarla o meno per i suddetti motivi. Ho paura a vincolarmi troppo
e non riuscire più a venirne fuori senza lunghi e complessi sistemi
di backup+restore con conseguente down dei servizi.
 
Un raid software, se dovesse andare tutto in vacca, prendo i dischi e li sposto
di server. 1 minuto ed ho risolto. 5 minuti nel caso dovessi cambiare anche
il tray dei dischi, proprio nella peggiore delle ipotesi.

 il tray dei dischi, proprio nella peggiore delle ipotesi.
 
Esatto.
 
Ora, ognuno decide per se, ma io ho sempre
avuto riscontri positivi con il RAID SW di
Linux, anche quando vi sono stati problemi.
 
Fai un po' di test, con 3 HDD o 3 SSD, vedi
che parametri sono modificabili e prova se
vi sono configurazioni ottimali per il tuo
uso ed in bocca al lupo... :-)
 
bye,
 
-- 
 
piergiorgio

 Due potrebbero anche bastare.
 
Due *vendor* intendo, non due SSD...
 
bye,
 
-- 
 
piergiorgio

 Linux, anche quando vi sono stati problemi.
 
Questo è vero, anche io.
Proprio in questi giorni ho sostituito un disco
guasto in un raid software operativo da circa 
SETTE anni. (ps: dischi SATA, nessuno dei miei dischi
SAS ha mai resistito tanto)

 SAS ha mai resistito tanto)
 
Secondo Backblaze gli HDD consumer hanno
"sopravvivenze" equivalente, forse migliori,
degli HDD enterprise.
 
bye,
 
-- 
 
piergiorgio

 bisogna fare due conti).
 
Continua a non essermi chiara una cosa.
Te parli di un RAID-1 a due dischi + spare, o 3 dischi simultanei?
Nel terzo caso: la probabilità che si spacchino tutti e 3 in tempi
pressochè identici è altissima. (do per scontato che il vendor dei
dischi sia il medesimo)
 
Nel primo caso, quando si spacca un disco, lo spare entra in
azione immediatamente ed in automatico. Bisogna sperare che durante
il rebuild non si spacchi l'altro disco.
 
Però, statisticamente, di che intervalli di sostituzione preventiva
si parla? 1 volta l'anno? 1 volta ogni 6 mesi?
 
Parlando di dischi meccanici, tolto partite difettose o casi d'uso particolari, 
un HDD tradizionale fa senza problemi almeno 2-3 anni di onorato servizio.
 
Un SSD? Perchè se devo stare con il timore di doverli cambiare ogni 2 mesi
proprio non mi va. Se invece la sostituzione preventiva la si effettua
ogni anno o giù di li, tutto cambia. Posso benissimo pianificare o, come te
suggerisci, schedulare un cronjob che automaticamente mi cambia un disco dei due con lo spare (che sarà opportunamente mantenuto spento fino al suo utilizzo)
 
Detto ciò: i valori smart di cui parli, indicano lo stato di usura dei dischi?
Sotto quale soglia conviene sostituire preventivamente il tutto ?
Sono affidabili ? Vorrei evitare di far affidamento a tali valori e poi ritrovarmi tutto all'aria. (come già capitato di recente: mi fidavo della controller e del suo consistency check finchè DUE dischi si son spaccati in simultanea senza che la controller si accorgesse di nulla. Cambio un disco, perdo tutto perchè era rotto anche l'altro. Raid1)
 

 Sono affidabili ? Vorrei evitare di far affidamento a tali valori e poi ritrovarmi tutto all'aria. (come già capitato di recente: mi fidavo della controller e del suo consistency check finchè DUE dischi si son spaccati in simultanea senza che la controller si accorgesse di nulla. Cambio un disco, perdo tutto perchè era rotto anche l'altro. Raid1)
 
Quelli sono parametri misurati, quindi salvo
bug software dicono esattamente cose sia
successo al SSD fino a quel momento.
 
Che poi le rotture rispettino le dichiarazioni
del costruttore, quella e` un'altra storia.
 
Ad ogni modo, forse se hai questi dubbi, ti
conviene semplicemente un RAID-1 con 3 SSD.
 
bye,
 
-- 
 
piergiorgio

 conviene semplicemente un RAID-1 con 3 SSD.
 
E nessuna rotazione ?
Perchè questa storia di usare 3 SSD uguali in RAID-1 proprio non mi convince.
Va contro ogni logica. E' risaputo che gli SSD si "consumano".
Se sono 3 SSD identici, in RAID-1 per forza di cose si consumeranno in maniera
identica e di conseguenza, si romperanno tutti e 3 assieme.
Se non lo fanno, è un puro caso. In pratica farei affidamento su una "anomalia"
 
In altre parole: a parità di utilizzo, 3 dischi meccanici si rompono nello stesso momento per pura sfiga. (più dischi metti, minore è il caso che si rompano tutti assieme)
3 SSD si rompono nello stesso momento per definizione.
3 SSD *non* si rompono nello stesso momento per pura fortuna, l'opposto esatto di un disco meccanico.

 3 SSD *non* si rompono nello stesso momento per pura fortuna, l'opposto esatto di un disco meccanico.
 
Tutto sbagliato, valgono le stesse regole,
sia per HDD che per SSD.
Gli HDD si rompono contemporaneamente tanto
quanto gli SSD.
Se fai RAID con HDD *uguali* hai buone probabilita`
di avere rotture multiple simultanee.
 
bye,
 
-- 
 
piergiorgio

 una distribuzione Gaussiana, con una certa
 
Ovviamente Gaussiana non modella sicuramente
il caso di rotture che aumentano al passare
del tempo e / o scritture.
 
Serve una distribuzione asimmetrica... Bah...
 
bye,
 
-- 
 
piergiorgio

 varianza, e *media* "1000 scritture".
 
Questa cosa non mi convince affatto.
Presumibilmente userò degli Intel S3610 da 200GB.
Specifiche:
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3610-spec.html
 
 
"Endurance: 3 drive writes per day for 5 years"
 
Sono drive di fascia enterprise, presumo che Intel non la spari grossa come si tende a fare in ambito consumer.
 
In RAID-1, tutti e 3 i dischi vengono scritti in egual misura, quindi, in egual misura si consumano.
 
La statistica di cui parli è valida per un evento straordinario del tipo: drive difettoso, si è rotto dopo 6 mesi e non dopo 3 anni.
Aumentando il numero di drive, scende il fattore sfiga ma aumenta la probabilità di guasto (più drive hai, più è probabile che qualcosa si rompa). Questo è palese.
 
Ma il limite di scritture resta, ed è il medesimo per tutti e 3 i drive, quindi, salvo guasti imprevedibili (dove la tua statistica è corretta), i 3 SSD si romperanno pressochè nello stesso momento attorno ai 3 anni, avendo tutti e 3 lo stesso identico workload.
 
Detto ciò, pensavo di fare un RAID-1 a 3 dischi (S3610 da 300GB) più hotspare. 4 dischi per server. Non so se buttarci dentro un Samsung 850 Pro, nei 3 dischi in RAID, giusto per avere qualche garanzia in più. Il Samsung è fascia consumer, non vorrei potesse dare problemi.....
 
Di dischi enterprise simili, per prezzo e caratteristiche, agli S3610 non ne conosco....

 Di dischi enterprise simili, per prezzo e caratteristiche, agli S3610 non ne conosco....
 
Non saprei, vi sono dei Samsung enterprise e,
forse, dei Crucial.
 
bye,
 
-- 
 
piergiorgio

 forse, dei Crucial.
 
Ok, ho trovato dei Samsung da datacenter.
Pertanto, farò 2 SSD Intel ed 1 Samsung. Può avere senso tenere un hotspare nella macchina, portando il tutto, di fatto, a 4 dischi ?
 
Tanto comunque dovrei tenere degli SSD di scorta, tanto vale tenerli già dentro in modo da farli attivare in automatico al bisogno, senza il mio intervento.
 
Per la sostituzione preventiva, che valori suggerisci di controllare e sopratutto, come suggerisci di operare ? Tolgo 1 disco a caso 3 tre sostituendolo con 1 nuovo (magari l'hotspare già presente) ?
 
Così: raid-1 a 3 dischi + hotspare. Dopo un po (quanto?) tolgo 1 disco ed attendo il rebuild su hotspare, nel frattempo aggiungo un ulteriore disco come hotspare.
 
Speriamo che tenere l'hotspare fermo per anni non abbia l'effetto contrario di attivare il disco e vederlo rotto dopo breve (come capita con i dischi meccanici, dopo anni di rotazioni inutili, non appena entra in funzione salta)

 Speriamo che tenere l'hotspare fermo per anni non abbia l'effetto contrario di attivare il disco e vederlo rotto dopo breve (come capita con i dischi meccanici, dopo anni di rotazioni inutili, non appena entra in funzione salta)
 
Come scritto prima, non dovrebbe.
Se li ruoti, pero`, non si pone il problema.
 
Se non li ruoti, forse vi e` una questione da
considerare. Il costo (e le prestazioni) degli
SSD cambia rapidamente col tempo, non so se sia
scaltro tenerne uno a far niente.
 
bye,
 
-- 
 
piergiorgio