Newsgroup: it.comp.hardware.storage
Titolo: SSD: TRIM in Linux con ext4

Posto qui una sintesi di quanto ho recentemente scoperto.
 
Usando il filesystem ext4 si può abilitare il supporto al "background
TRIM" usando al mount l'opzione "discard".
 
L'opzione fa il suo lavoro *solo* *se* il filesystem ha un *journal*.
Ext4 di default ha il journal, ma spesso si leggono suggerimenti
che consigliano di disabilitarlo sugli SSD, per minimizzare il
numero di scritture[*]: in tal caso si sappia che l'opzione discard,
cioè il "background TRIM", *non* funzionerà. Tuttavia si potrà
eseguire comunque un TRIM periodico, usando il comando fstrim di
tanto in tanto (magari mettendolo in crontab): fstrim funziona anche
senza journal.
 
[*] In realtà l'impatto del journal è davvero basso, e del tutto
accettabile:
http://tytso.livejournal.com/61830.html
 
https://wiki.archlinux.org/index.php/Solid_State_Drives#Disabling_Journaling_on_the_Filesystem.3F
 
 
 
Mi è stato anche fatto notare che, benché sia ben possibile verificare
se il TRIM sia attivo o meno, è tuttavia impossibile controllare
come il firmware dell'SSD risponda al TRIM (che è un comando solo
informativo: dice al firmware quali filesystem blocks sono tornati
liberi da occupati che erano), e cioè se e quanto velocemente il 
firmware resetti le celle di memoria corrispondenti a tale spazio
liberatosi. Ciò perché, anche se richiamando il contenuto di tali
celle esse appaiono come resettate (test che permette di stabilire
se il TRIM è attivo oppure no), è altamente probabile che in
realtà il firmware semplicemente spesso mentisca su tale contenuto,
*fingendo* di averle immediatamente resettate pur non avendolo fatto
(atteggiamento attendista estremamente indicato in molti casi) e
riservandosi di resettarle davvero solo quando la cosa sia necessaria
o conveniente. E senza hardware dedicato non si può bypassare il
firmware per leggere direttamente la flash.
 
La storia completa qui in questi thread:
http://groups.google.com/group/it.comp.os.linux.iniziare/browse_thread/thread/9fe19f3e8212106f/fca7c02087228d59?hl=it
 
http://groups.google.com/group/it.comp.os.linux.iniziare/browse_thread/thread/7d2f85fe560a497a/d69e6fe354629c88?hl=it
 
http://ubuntuforums.org/showthread.php?t=1873958
 
http://phoronix.com/forums/showthread.php?64581-Ext4-discard-option-(AKA-TRIM)-not-working-on-SSD-Crucial-M4-64GB
 
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://dnahome.cs.rpi.edu/dna/
 
 
http://www.gpugrid.net/
 

 firmware per leggere direttamente la flash.
 
in effetti il TRIM "elettrico" impiega del tempo, nel tuo caso sono
pochi MB quindi e' eseguito in tempo reale, al contrario per 5-10GB
occorrono diversi secondi (dopo il ritardo di esecuzione)
 
se il firmware eseguisse il TRIM "elettrico" solo quando necessario
(esaurimento delle celle libere) perderebbe tutti i suoi vantaggi derivanti
proprio dall'essere eseguito in modo preventivo, vale lo stesso per un
BGC poco aggressivo
 
ho letto anche la tua osservazione sull'inefficienza del TRIM
nel caso di eliminazione di poche pagine dello stesso blocco,
siccome sappiamo poco del funzionamento del firmware
possiamo ipotizzare che l'effettiva esecuzione elettrica avvenga
solo per pagine con molti blocchi "sporchi", a tal proposito
ci sono gli indicatori di wear range globali, nell'evenienza che
questi raggiunga la soglia imposta il trim eletrico interviene
a prescindere dal numero di blocchi "sporchi"
 
sempre ipoteticamente si puo' pensare che quando un blocco e'
mappato come vuoto (anche se non e' stato ancora "trimmato"
elettricamente) viene interpretato come "tutti zeri" anche se
contiene ancora "dati sporchi"
 
sono tutte ipotesi ma sono sicuro che anche con il sorgente
alla mano non riuscirei a capirci piu' di tanto ;)
(ammesso che abbia capito bene le prove da te effettuate)
 
aspetto il cambio di piattaforma per prendere un m4 , non
per effettiva necessita' ma per riciclare il V2 in un altro sistema
(come mai sei ancora al firmware 0002 ?)
 
ciao
luca
 
 
 
 

 (come mai sei ancora al firmware 0002 ?)
 
Avevo letto il tuo articolo sul 9, se ben ricordo. Mi pareva concludessi 
che non dava miglioramenti su i/o e accessi random, che è quello che 
interessa a me - quindi poi ho desistito.


 non grafici. Vedo di cercare altro.
 
È carino nmon.


 interessa a me - quindi poi ho desistito.
 
si', la recensione su Storage Review e' l'unica che aveva messo
in evidenza l'appiattimento degli IOPS al crescere delle richieste
(con QD>8) , e' sempre una simulazione con IOMeter che potrebbe
non avere riscontri nelle applicazioni reali (come e' infatti avvenuto
nelle altre recensioni) ma in ambiti specifici potrebbe fare la differenza
http://www.storagereview.com/crucial_m4_ssd_review_firmware_0009
 
 
un altro vantaggio del nuovo firmware e' la minore latenza in
scrittura, non quella media che e' sostanzialmente simile
ma quella di picco
 
sarebbe interessante sapere se si puo' tornare al vecchio
firmware (0002) riprogrammando dal nuovo (0009)
 
ciao
luca
 
 
 

 [...]
 
Per diversi motivi io personalmente non posso fare una cosa del genere: 
primo fra tutti dovrei spendere troppo tempo, anche per cercare di capire 
come agire in concreto. :(
 
'Scolta... se il giornale risiede sulla medesima partizione del filesystem 
cui si riferisce, cioè se è interno, non è altro che un file nascosto - 
nascosto in modo un po' particolare, ma quello è. Ma può stare anche 
altrove.
 
Se il nostro obiettivo è quello di vedere quanto e come viene usato il 
giornale di ext4 a fronte di certe operazioni, non ci interessa usare per 
forza l'SSD (cosa che introduce complicazioni notevoli): IMHO è meglio 
usare due partizioni qualsiasi: una per il filesystem puro, una per il 
giornale *esterno*.
 
Poi monitoriamo quanti dati vengono scritti sul device che accoglie il 
giornale, e quante operazioni vengono fatte lì sopra. Dopodiché valutiamo 
se il numero di operazioni in più sia problematico per un SSD.
 
Così, volendo, si possono fare molti test più brevi e apprezzare anche 
l'impatto di diversi ioscheduler, di diverse opzioni di mount di ext4...
 
BTW: sarebbe bello poter usare due dischi ram, ma ho visto che con quelli 
il monitoraggio non funge.
 
Che ne dici?


 Che ne dici?
 
dico che si puo' fare ma il giornale va sempre su SSD altrimenti non si
puo' misurare il WA , ma solo l'overhead sull'host write (non sulle NAND)
 
quindi il problema torna al punto iniziale, la granularita' di misurazione
 
ho un Vertex 2 che posso usare come cavia ma ha il problema che
indica le scritture a passi di 256GiB , poi c'e' la compressione
che con un file di tipo log arrivera' all'80-90%, quindi non credo di
riuscire a calcolare il WA con sufficiente precisione , per ottenere
256GiB di overhead dovrei scrivere una cinquantina di TiB (!)
 
ho anche un Vertex 30GB (indilinx) che indica i settori scritti
(precisione 4KiB), purtroppo non posso smontarlo per fare prove
ma sarebbe l'ideale (ci si mette solo il giornale)
 
 
ciao
luca
 
 
 

 NAND)
 
Uhm, a me quella di voler calcolare indirettamente anche il WA pare 
un'impresa disperata. Sarebbe bello, però...


 un'impresa disperata. Sarebbe bello, però...
 
se il journal incide del 4% , come da primi due esempi di
ArchWiki, secondo me non ne vale la pena, pero' se
si supera il 10% fino al 40% (terzo esempio) direi che
e' un aspetto su cui indagare
 
come al solito dipende dal tipo di utilizzo del sistema e dal carico
di lavoro
 
si potrebbero fare delle ulteriori indagini sull'efficienza in
scrittura dei vari scheduler bilanciando prestazioni e WA
 
ciao
luca
 
 
 
 
 
 
 
 
 

Ho trovato estremamente interessante tutto il vostro discorso.