Newsgroup: it.comp.os.linux.sys
Titolo: SATA vs SAS vs SSD

Stavo guardando un po di specifiche sui livello di affidabilità.
uno dei valori più importanti è l'URE.
 
Mediamente, nei SATA, si aggira ad 1 settore ogni 10^14, nei SAS 1 settore ogni 10^16, negli SSD (ad esempio gli Intel DC) ad 1 ogni 10^17
 
se è realmente vero, gli SSD sono di un ordine di grandezza più affidabili dei SAS e per loro natura, dovrebbero essere anche più prevedibili in termini di guasti (c'è il monitoraggio del wearout)
 
E' veramente così ? A livello elettrico/elettronico, un SSD può morire da un momento all'altro tanto quanto un disco SAS o SATA (componenti bruciati etc etc), ma a livello "meccanico" gli SSD dovrebbero essere molto più prevedibili, si consumano pian piano, si monitora lo status di usura e via andare.
 
In pratica, salvo imprevisti che capiterebbero a qualunque apparato elettroncio, un SSD non dovrebbe cedere di botto, a differenza di un disco meccanico che inizia a riallocare settori da oggi a domani.


Questa frase che senso ha?
 
"un SSD non dovrebbe cedere di botto, a differenza di
un disco meccanico che inizia a riallocare settori da
oggi a domani."
 
Riallocare settori *non* e` cedere di botto, e` quello
che si chiama "graceful degradation".
Esattamente l'opposto.
 
Ed e` esattamente il problema dei SSD.
Questi cedono di botto senza preavviso, tanto che,
come gia` scritto piu` volte, si consigliano 3 SSD
(*tre* SSD) in RAID-1.
 
L'URE e` solo uno dei parametri, importante, ma
lascia anche il tempo che trova.
 
bye,
 
-- 
 
piergiorgio

 lascia anche il tempo che trova.
 
Ok, ma se sommi l'URE, che è comunque di un ordine di grandezza superiore ad un SAS e 2 ordini di grandezza superiore ad un SATA, sommi il numero di scritture totali garantite per giorno (ad esempio 3, per 5 anni), sommi il valore del wearout, dovresti avere un numero di parametri tale da poter monitorare l'usura in maniera piuttosto efficace.
 
Tutto ciò, con un disco meccanico è impossibile.
 
Un SSD con URE 1*10^17 è già più affidabile (non di poco, almeno sulla carta) di un SAS 1*10^16, sai che può essere scritto e cancellato completamente 3 volte al giorno per 5 anni, sai che sei ancora al 99% di consumo, sai che in media lo stai scrivendo meno di 1 volta al giorno (disco da 200GB, ne scrivo solo 150 al giorno), direi che sei un pezzo in la con il monitoraggio. dovresti avere una panoramica piuttosto affidabile dello stato del disco.
 
Con un SAS, questo te lo scordi, non hai una usura "prevista", non hai un consumo da monitorare, etc etc. Sai che prima o poi, lui inizia a cedere.
 
Considera, poi, che stando alle specifiche intel, ci sono le riallocazioni dei settori anche negli SSD. Un settore danneggiato, viene ritornato come non leggibile, esattamente come un disco meccanico. Forse i tempi in cui un SSD cede di botto senza preavviso son finiti? Magari ora iniziano a riallocare le celle ?
Altrimenti non si spiegherebbe la presenza in SMART del numero di settori riallocati.

 Altrimenti non si spiegherebbe la presenza in SMART del numero di settori riallocati.
 
Ed e` lo stesso per gli HDD.
Anche con questi hai i settori riallocati.
 
In generale, tutte le possibilita` di monitorare
sono presente in HDD e SSD.
Piu` le varianti del caso (parametri meccanici vs.
parametri elettronici).
 
La maggiore differenza e` che per gli HDD vi sono
decenni di esperienza ed i parametri SMART sono
abbastanza affidabili.
Per gli SSD questa esperienza non c'e`, al punto
che diventa difficile capire lo stato ed anche
prevedere una rottura.
 
Certo, quando finiscono i settori liberi, si deve
cambiare, ma questo e` solo uno delle possibilita`.
Ed e` presente anche negli HDD. Con che risultati?
 
bye,
 
-- 
 
piergiorgio

 parametri elettronici).
 
Mica vero.
Gli SSD hanno parametri differenti da quelli SATA ed i parametri
sono gestiti dal disco. 
E' il disco che ritorna determinati valori, tant'è che non tutti gli SSD 
ritornano tutti i parametri.
 
Ad esempio questo è il mio SSD del portatile:
 
  5 Reallocated_Sector_Ct   0x0003   100   100   000    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0003   100   100   000    Pre-fail  Always       -       1720
175 Program_Fail_Count_Chip 0x0003   100   100   000    Pre-fail  Always       -       0
176 Erase_Fail_Count_Chip   0x0003   100   100   000    Pre-fail  Always       -       0
177 Wear_Leveling_Count     0x0003   100   100   000    Pre-fail  Always       -       49646
178 Used_Rsvd_Blk_Cnt_Chip  0x0003   100   100   000    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0003   100   100   000    Pre-fail  Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0003   100   100   005    Pre-fail  Always       -       1664
181 Program_Fail_Cnt_Total  0x0003   100   100   000    Pre-fail  Always       -       0
182 Erase_Fail_Count_Total  0x0003   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0003   100   100   000    Pre-fail  Always       -       0
195 Hardware_ECC_Recovered  0x0003   100   100   000    Pre-fail  Always       -       0
241 Total_LBAs_Written      0x0003   100   100   000    Pre-fail  Always       -       102154
242 Total_LBAs_Read         0x0003   100   100   000    Pre-fail  Always       -       337954
 
 
 
Questo è quello di un DC3610 Intel:
 
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       324
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       17
170 Unknown_Attribute       0x0033   100   100   010    Pre-fail  Always       -       0
171 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
174 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       16
175 Program_Fail_Count_Chip 0x0033   100   100   010    Pre-fail  Always       -       4298120134
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   071   000    Old_age   Always       -       29 (Min/Max 24/29)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       16
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       29
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
225 Unknown_SSD_Attribute   0x0032   100   100   000    Old_age   Always       -       151309
226 Unknown_SSD_Attribute   0x0032   100   100   000    Old_age   Always       -       163
227 Unknown_SSD_Attribute   0x0032   100   100   000    Old_age   Always       -       49
228 Power-off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       19417
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   Always       -       0
234 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       151309
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       148963
 
 
 
sono di più e sono diversi.
 
Resta comunque il fatto che non mi capacito di come sia possibile avviare una intera attività basata esclusivamente su SSD in RAID (come molti servizi di hosting sia nazionali che internazionali)
 
Quindi, o gli SSD sono decisamente più affidabili dei SAS, oppure tutte queste aziende sono fuori di testa.

 altamente discutibile.
 
Tanto per capire il problema.
 
Un URE 10E17 vorrebbe dire, credo, che c'e` un
bit sbagliato ogni non meno di 10E17 bit letti.
Sbagliato nel senso di "non correggibile".
Non si sa se sia *riconosciuto* come sbagliato,
ma penso di no.
Per poter misurare tale valore in senso
statistico, bisogna leggere *almeno* 10E20
bit e trovare circa 1000 errori.
10E20 bit sono poco meno di 2E67 bit.
Cioe` 2E64 byte.
 
1GB sono 2E30 byte.
 
Ora, diciamo che si riesca a leggere (ed anche
verificare) 1GB/sec, servono 2E34 secondi per
potere ricavare l'URE.
 
Se non sbaglio i conti, questo sono quasi 545 anni.
 
Ora, visto che non e` possibile abbiano usato
per 545 anni un SSD, deve esserci un altro modo.
 
Non mi risulta, ma potrei semplicemente essere
ignorante, questo altro modo sia specificato.
 
Probabilmente, l'URE e` ricavato in base a
qualche considerazione statistica, basata su
qualche misura secondaria e qualche modello.
 
Potrebbe benissimo essere che 10E17 sia una
misura cautelativa, magari in realta` e` 10E20.
 
O magari la buttano li`, tanto chi riesce a
verificarne il valore... Anche fosse 10E12,
servono sempre oltre 17 anni...
 
bye,
 
-- 
 
piergiorgio

 Quindi, o gli SSD sono decisamente più affidabili dei SAS, oppure tutte queste aziende sono fuori di testa.
 
Semplicemente usano piu` ridondanza.
 
Dipende poi dal problema.
 
Se serve capacita`, allora non c'e` SSD che tenga, si
deve andare di HDD e persino SATA, come fa Backblaze
(che tra l'altro dice che SATA e SAS, nonostante le
specifiche differenti, sono affidabili uguale, anzi
SATA meglio di SAS).
 
Se servono transazioni al secondo, allora si puo`
usare solo SSD. 3xRAID-1, se si vuole stare sicuri.
 
bye,
 
-- 
 
piergiorgio

 usare solo SSD. 3xRAID-1, se si vuole stare sicuri
 
No, perché tutte le aziende che ho visto parlano di raid hardware e conosco solo una controller che supporta raid1e a 3 dischi: la smartarray
 
E tutti parlano di raid10 (follia secondo me) o raid6

 ignorante, questo altro modo sia specificato.
 
Non funziona proprio così.
Un URE di 10^14, tipico dei SATA, è pari a 12.5TB di dati letti
Questo spiega perchè un RAID-5, con le dimensioni attuali dei dischi, è oggigiorno una follia e quindi non consigliato più da nessun vendor.
 
Ad esempio un RAID-5 a tre dischi da 8TB, in caso di rebuild, genererebbero 16TB di letture, è quasi matematico beccare un URE.
 
Su questo però c'è da sindacare, perchè l'URE è sul singolo disco, quindi ciascun disco può essere letto fino a 12.5TB, nel RAID-5 di cui sopra i dischi da cui leggere sono 2, quindi entrambi hanno URE 10^14, ovvero 25TB di dati leggibili.
Ma questo nessuno lo considera, quindi forse sbaglio io.
 
Detto ciò:
 
URE 10^15 =   125TB
URE 10^16 =  1250TB (tipico dei SAS)
URE 10^17 = 12500TB (SSD Intel)
 
Sono sicuramente valori statistici, ma presumo piuttosto affidabili e veritieri perchè su questo dato, si calcolano i vari livelli RAID.
 
La dismissione del RAID-5 da parte di *tutti* i vendor è data esclusivamente dal valore di URE non aumentato nonostante la capacità dei dischi sia cresciuta in maniera esponenziale. Se l'URE fosse un valore trascurabile, non ci sarebbe nemmeno alcun criterio di selezione RAID. Fanne uno a caso e sei a posto.
 
Resta comunque il fatto che gli SSD in questione hanno un valore di URE superiore alla loro stessa vita, ovvero 3 letture/scritture complete al giorno per 5 anni, quindi:
 
200GB*3*365*5 = 1095000GB = circa 1.1PB.
L'URE è 12.5PB
 
Sulla carta gli SSD sono di qualche ordine di grandezza più affidabili rispetto ad un SAS. E' questo che mi stupisce. Oltretutto per gli SSD vengono dati, come dati di targa, tutta una serie di valori non presente nei dischi meccanici, quali appunto il numero di letture/scritture complete.
 
Bada bene: parlo di SSD fascia enterprise/datacenter come gli Intel DC3610 o superiore, non del Samsung che compri al Mediaworld con 50 euro.
 
C'è un paper di google (che non trovo, ma ho letto su un sito online) che però dice che gli errori di lettura degli SSD sono più frequenti dei dischi meccanici, questi ultimi però tendono a rompersi più facilmente.
 
boh, non ci capisco nulla

 Un URE di 10^14, tipico dei SATA, è pari a 12.5TB di dati letti
 
E questo numero da dove viene?
Da dove lo hai tirato fuori?
 
10E14~=2E47
 
Che sono 2E17 Tbit, cioe` 128Pbit, che sono 16PB.
 
Oppure sbaglio i conti io?
 
bye,
 
-- 
 
piergiorgio

 E tutti parlano di raid10 (follia secondo me) o raid6
 
Con SSD un RAID-10 va benissimo.
Tra l'altro e` scalabile in ridondanza.
 
I RAID-5/6 possono essere un problema per varie
ragioni, non ultima il TRIM.
 
bye,
 
-- 
 
piergiorgio

 No, perché tutte le aziende che ho visto parlano di raid hardware e conosco solo una controller che supporta raid1e a 3 dischi: la smartarray
 
Pare che la tecnica usata (in caso di controller
non troppo furbo) sia:
 
(1+1)+1
 
Cioe` 2 dischi in RAID-1 e poi il RAID-1 con
altro disco ancora in RAID-1.
 
Pero` qualcuno scriveva di controller che
consentono piu` di due dischi in RAID-1.
Non saprei...
 
bye,
 
-- 
 
piergiorgio

 Un URE di 10^14, tipico dei SATA, è pari a 12.5TB di dati letti
 
Aspetta, forse ho capito (e` l'ora tarda...):
 
10E12 == 1Tbit
 
Quindi 10E14 == 100Tbib == 12.5TB
 
10E14 ~= 2E47
 
10E12 ~= 2E40 e non 2E30 come avevo scritto.
 
Quindi 2E7 TB == 128TB circa come sopra.
 
Ma il punto resta che per poter *determinare* questa
statistica bisogna trovare almeno 100~1000 errori.
Quindi siamo 1000 volte sopra il data rate minimo.
 
Non bastano 12.5TB di dati, ne servono almeno 1000
volte tanto.
Quindi 12.5PB.
 
Il problema non e` l'errore ogni 12.5 TB, il problema
e` *misurare* quell'errore.
 
Cioe` come fanno a dichiarare un URE di 10E14 o 10E17,
dato che devono leggere 10E17 o 10E20 dati per poter
avere dei valori "robusti"?
 
bye,
 
-- 
 
piergiorgio

 settore ogni 10^16, negli SSD (ad esempio gli Intel DC) ad 1 ogni 10^17
 
  Ma SATA e SAS non sono tecnologie di realizzazione del supporto dei
dati com'è invece lo SSD, sono piuttosto interfacce e protocolli di
trasferimento dati.  La quasi totalità degli SSD per PC e portatili sono
SATA, infatti.
 
 
  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.

 Oppure sbaglio i conti io?
 
L'URE è in bit, basta fare la conversione:
 
((1*10^14)/8)/1000/1000/1000/1000 = 12.5 TB
 
Ha un bit ogni 12.5TB che potrebbe non funzionare.
Questo nei dischi SATA tradizionali.
Nel mio caso uso seagate SAS, sulla carta (tutti i dischi SAS) hanno 10^16:
((1*10^16)/8)/1000/1000/1000/1000 = 1250 TB
 
Ma tutto ciò collide con ciò che dicono i vari vendor.
Sconsigliano (tutti) il raid-5 a prescindere, e non il raid-5 con dischi SATA.
Per i SATA ci può stare, sono talmente grandi che un singolo disco (mi sembra tanto una stronzata) letto 1 volta e mezzo supererebbe il suo stesso URE:
https://www.wdc.com/content/dam/wdc/website/downloadable_assets/ita/spec_data_sheet/2879-800002.pdf
 
 
10^14 e 8TB di disco. In pratica lo leggi tutto una volta e mezzo.
Se ne metti 3 in RAID-5, le probabilità di ricostruire il raid sono 0, dato che leggeresti 16TB ad ogni ricostruzione.

 Tra l'altro e` scalabile in ridondanza.
 
Non mi fido affatto. La probabilità che si rompano due dischi dello stesso
mirror è tangibile, sopratutto su grossi array. Ed a me è capitato quest'anno.

 Non saprei...
 
Le SmartArray HP si.

 SATA, infatti.
 
Si certo. Ma non capisco il nesso.
Solitamente i dischi SATA vengono controllati meno, magari usano fabbriche meno tecnologiche e materiali meno pregiati, considerato il loro utilizzo desktop rispetto ai SAS di fascia enterprise.
 
Poi ovviamente SAS e SATA è solo l'interfaccia, ma anche la meccanica del disco spesso cambia (tant'è che i SAS sono anche più veloci ed hanno specifiche sempre superiori ai SATA).
 
Di sicuro un disco SAS non è semplicemente un SATA con interfaccia differente.


No, infatti.
 
Sarebbe pero` meglio distinguere tra "consumer"
ed "enterprise".
Accidentalmente in questo secondo si usa SAS.
Questo perche` il segnale SAS ha un livello piu`
alto, quindi e` meno sensibile al rumore, rispetto
al segnale SATA (pur restando compatibili).
 
Esistono, pero`, dischi SATA "enterprise".
 
Ad ogni modo, i dischi "enterprise" hanno, tra le
varie cose, piu` bit per la correzione d'errore.
 
Questo diminuisce (od aumenta, dipende da come la
si vede) l'URE e rende il disco piu` lento.
 
bye,
 
-- 
 
piergiorgio

 L'URE è in bit, basta fare la conversione:
 
Si, infatti, avevo un conto sbagliato.
 
Resta pero` il fatto su come si *misuri* tale errore.
 
Se tu hai una moneta, come fai a sapere se la
probilita` T/C e` 50/50 o 60/40 o 99/1?
 
Devi fare molti lanci, da 100 a 1000 rispetto
all'esperimento base.
Nel caso 99/1 devi fare almeno 10.000 (cioe`
cento volte il 99/1) lanci.
Per mia esperienza, 100 volte non sempre basta,
a volte serve 200 o 500 o 1000.
Per sicurezza, magari 1000.
 
Quindi se uno dice che X ha un URE di 10E17, devi
leggere *almeno* 10E20 bit e trovare 1000 errori,
per poter *verificare* quel 10E17.
 
Quanto ci vuole per leggere 10E20 bit con un
interfaccia SAS a 6Gbit/sec?
 
Troppo tempo (500 anni?) per fare una verifica
in questo modo.
 
Esistono trucchi, per esempio fare il test a 70
gradi Celsius o piu`.
Questo aumenta la probabilita` d'errore, ma si
deve conoscere il modello, cioe` la relazione tra
errore e temperatura.
 
Ad ogni modo, se non viene specificata la metodologia
in base alla quale l'URE e` calcolato, resta un dato
di fede.
 
Di conseguenza, pur essendo valido confrontare URE
tra diversi prodotti, bisogna farlo cum grano salis.
 
Infine, l'URE non tiene conto della probabilita` di
disastro, cioe` che il dispositivo semplicemente non
risponda piu`.
Che e` il caso tipico degli SSD (e non il bit error).
 
bye,
 
-- 
 
piergiorgio

 mirror è tangibile, sopratutto su grossi array. Ed a me è capitato quest'anno.
 
Certo, ma puoi fare strutture piu` ridondanti di 2+2.
Quelli di LSI non dicono che il RAID-10 puo` avere
fino a... boh... 8? 10? dischi?
 
Il caso "classico", pero`, e` solo un pelo meglio di
un RAID-5.
Questo ultimo sicuramente e` sconsigliato.
 
Infatti, si consiglia, per motivi prestazionali, sempre
un RAID-51 (o 15, non saprei) contro RAID-10 o RAID-5
da soli (RAID-6 andrebbe bene, ma e` piu` lento).
 
bye,
 
-- 
 
piergiorgio

 da soli (RAID-6 andrebbe bene, ma e` piu` lento).
 
RAID-51 ovvero un RAID-5 replicato?
Oppure 3 RAID-1 replicati in RAID-5?
Mai vista una cosa simile, *nessun* controller li supporta.
Il RAID-51 potrebbe avere quasi un senso (limitato), il 15 proprio no,
butti via 3 dischi alla volta. Fai un RAID-60 e vivi felice, dato che
dovresti perdere 3 dischi per ciascun RAID-6 prima di trovarti gambe all'aria.

 Oppure 3 RAID-1 replicati in RAID-5?
 
Due RAID-5 in mirror.
DELL sicuramente offre questa soluzione, visto
che e` usata da un mio conoscente.
 
bye,
 
-- 
 
piergiorgio

 che e` usata da un mio conoscente.
 
Su quali dispositivi ?
Forse-forse su Equallogic o simili, ma sulle controller RAID attuali non mi pare proprio ci sia la possibiltà.

 Forse-forse su Equallogic o simili, ma sulle controller RAID attuali non mi pare proprio ci sia la possibiltà.
 
Mah, mi sembra molto strano, dato che i RAID combinati
sono standard.
 
Non ho informazioni specifiche, ma io credo che i
controller RAID HW siano in grado di combinare
piu` livelli.
 
Altrimenti che senso ha parlare di questi tipi di RAID?
Solo per la versione SW? Non credo.
 
bye,
 
-- 
 
piergiorgio

 Solo per la versione SW? Non credo.
 
Dati alla mano, PERC H830, attuale top di gamma di DELL:
http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-PowerEdge-RAID-Controller-H830.pdf
 
 
"RAID levels 0, 1, 5, and 6
RAID spans 10, 50, and 60"
 
RAID-1E e RAID-51 non sono supportati.
 
Non è proprio supportato dal chipset: 
http://docs.avagotech.com/docs/LSISAS3108
 
Il RAID-1E è supportato solo quando integrato sulla scheda madre (ad esempio in alcuni server supermicro)
 
Gli HP abbiamo già detto che supporta RAID-1E ma non RAID-51:
https://www.hpe.com/h20195/v2/getpdf.aspx/c04346277.pdf?ver=5
 
"RAID 0, 1, 10, 5, 50, 6, 60, 10 ADM (Advanced Data Mirroring)"
 
Resta sostanzialmente Lenovo, che se ben ricordo usa gli stessi chip LSI, quindi anche li non c'è alcun RAID-51/RAID-1E
 

 Si certo. Ma non capisco il nesso.
 
   Eppure è evidente.  Confrontare l'URE di un SATA con quello di un
SSD, quando ci sono moltissimi SSD che sono SATA, che senso ha?  È come
confrontare la tenuta delle Goodyear con la tenuta delle Alfa Romeo.


 confrontare la tenuta delle Goodyear con la tenuta delle Alfa Romeo.
 
Ma è scontato che si stia confrontando *il disco* e non l'interfaccia, ho scritto SATA per semplificare, ma in realtà avrei dovuto scrivere: l'ure di un disco meccanico desktop rispetto ad un disco meccanico di fascia enterprise rispetto ad un SSD enterprise. Va meglio così?
 
Ma comunque come scritto in precedenza, in base al tipo di interfaccia, i dischi sono comunque differenti.
 
I dischi su interfaccia SATA sono qualitativamente più economici rispetto a quelli su interfaccia SAS, dato che la SAS è usata, 9 volte su 10, in ambito enterprise.
 
Tant'è che anche per gli SSD sto parlando di SSD di fascia enterprise/DC, non di dischi consumer che trovi al mediaworld, indipendentemente dal fatto che hanno una interfaccia SATA.
 

 Un SSD con URE 1*10^17 è già più affidabile (non di poco, almeno sulla carta) di un SAS 1*10^16, sai che può essere scritto e cancellato completamente 3 volte al giorno per 5 anni, sai che sei ancora al 99% di consumo, sai che in media lo stai scrivendo meno di 1 volta al giorno (disco da 200GB, ne scrivo solo 150 al giorno), direi che sei un pezzo in la con il monitoraggio. dovresti avere una panoramica piuttosto affidabile dello stato del disco.
 
 
Il numero di scritture sembra essere il valore più corretto per valutare l'usura,
almeno stando a quanto si legge in giro per la rete.
 
Se il DC3610 da 200GB [1] è dato a 1.1PB, su uno dei miei hypervisor, dove ho cambiato il disco 18425 ore fa (2 anni), ho scritto solo 38991,102 gigabytes, ovvero 39TB, direi che sono ampiamente al sicuro.
 
Le letture, poi, non dovrebbero comportare alcuno stress al disco, a differenza dei dischi meccanici e nel mio caso le letture in 2 anni sono 80571,732 GB
(questo è uno degli 8 dischi facenti parte del RAID-6, ma le scritture si aggirano grossomodo attorno alle stesse cifre: da 36500GB a 39000GB)
 
[1] 
http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-s3610-spec.pdf
 
 
P.S: come può un RAID-6 avere 1.5TB di differenza, in termini di scritture, tra i vari membri dell'array?

 P.S: come può un RAID-6 avere 1.5TB di differenza, in termini di scritture, tra i vari membri dell'array?
 
Se le scritture sono "piccole", cioe` meno (o esattamente)
di un "chunk", e` possibile, se il controller e` furbo,
scrivere solo il "chunk" in questione e le due parita`.
 
Quindi solo 3 dischi vengono scritti.
Se l'array, per es., ha 10 dischi, allora e` chiaro che
possono esservi differenze.
 
Se 1.5TB sia tanto o poco, non saprei dirti.
 
Immagino che fossero email, allora, col tempo, forse si
potrebbe arrivare a quel numero.
 
bye,
 
-- 
 
piergiorgio

 fascia enterprise rispetto ad un SSD enterprise. Va meglio così?
 
  Altro che meglio: così è finalmente corretto.


 potrebbe arrivare a quel numero.
 
In realtà è un hypervisor Xen con circa 30VM sopra.
Di traffico email, in queste 20-25VM, c'è ben poco. 
Sono per buona parte webserver e un paio di dns
 
Comunque di solito tra webserver e email cambia poco, la dimensione
delle scritture è sempre mediopiccola. Cambia però il numero delle
letture, un webserver è mediamente molto più stressato.

 letture, un webserver è mediamente molto più stressato.
 
Se sono scritture piccole, e` possibile, come
scritto sopra, se il controller ne ha la capacita`,
che solo pochi "blocchi" vengano riscritti e non
tutto lo stripe (cioe` tutti i dischi).
 
bye,
 
-- 
 
piergiorgio