Newsgroup: it.comp.os.linux.iniziare
Titolo: Ulteriori considerazioni su discard, TRIM e fstrim

.
 
Invece fstrim, il trim "manuale", funziona. Il problema è che funziona un
po' *troppo*.
 
Permettetemi una PREMESSA, in parte OT. Chi sa già, salti pure.
 
Sui dischi meccanici l'unità minima di scrittura e di lettura è il settore
fisico: 512B o 4kB. Inoltre un settore può essere sovrascritto senza
alcuna precauzione: non vi è differenza fra scrittura e sovrascrittura.
 
Negli SSD l'unità minima di scrittura e lettura è la pagina: sono 4kB. Ma
una pagina, che sia stata già scritta, non può essere sovrascritta
immediatamente. Prima dev'essere cancellata, o meglio "resettata": per far
la qual cosa, IIRC, tutti i suoi bit devono essere prima portati a 1.
 
Il problema è che, negli SSD, l'unità minima di cancellazione, o meglio di
"reset", non è la pagina: è il blocco, e un blocco è fatto di molte
pagine. Sul mio Crucial M4 è fatto di 128 pagine: quindi i blocchi sono di
4kB*128=512kB.  Su alcuni SSD i blocchi sono addirittura di 1MB. Se
intendo proprio sovrascrivere un byte di una pagina, devo prima 
resettarlo: cioè devo resettare tutti i 512kB del blocco cui quella 
pagina appartiene. Il blocco, per poter essere resettato, naturalmente 
non deve contenere alcun dato utile: dev'essere fatto tutto di pagine 
eliminabili (discard-able) o vuote.
Di quali celle occupare in scrittura, e di quando e cosa resettare, si
occupa il firmware dell'SSD: lo fa obbedendo in primis a logiche di wear 
leveling.
 
Il TRIM è un comando che mette in comunicazione il filesystem col firmware
dell'SSD. Quando un block del filesystem (occhio a non confonderlo col
blocco dell'SSD, non c'entrano nulla l'uno coll'altro), da occupato che
era viene reso nuovamente disponibile (per esempio per una cancellazione
del file cui il block apparteneva), normalmente il fs non informa il disco
e si tiene l'informazione per sé. Ciò ha perfettamente senso se il disco è
meccanico, perché i settori su cui il block giace potranno essere
riscritti al volo senza problemi. Ma ormai sappiamo che per un SSD è
diverso. Il TRIM semplicemente dice al firmware dell'SSD che il tal block
del filesystem è stato reso disponibile, e che quindi - quando e se il
firmware lo riterrà opportuno - quello spazio si potrà resettare. Il
firmware, a questo punto, ha tutti gli elementi che gli servono per poter
gestire i reset in modo da:
 
1) non allontanarsi mai troppo dalla condizione ottimale in cui le pagine
utili sono concentrate in certii blocchi, e quelle immediatamente
disponibili in altri;
 
2) preservare le celle di memoria da un'eccessiva usura, assicurando il
numero di reset eseguiti cresca in modo omogeneo per tutte le celle (wear
leveling).
 
Fine della PREMESSA. Procediamo.
 
Nel test per verificare se il trim funziona[*], bisogna creare un file,
cancellarlo e vedere che succede. Si consiglia di creare un file di almeno
una certa dimensione per essere sicuri (a meno di estrema frammentazione
dell'SSD) che un suo *intero* blocco (nel mio caso, di 512kB) venga 
occupato dal file. Questo perché solo se un blocco *intero* è stato 
occupato, e poi viene nuovamente indicato come disponibile, ha 
sicuramente senso resettarlo *immediatamente*. Invece, se solo alcune 
pagine del blocco fossero scritte e poi rese di nuovo disponibili, 
resettarle subito sarebbe discrezionale, e dipenderebbe molto dalle 
condizioni del resto del disco: probabilmente per il firmware sarebbe più 
sensato aspettare, e questo per un motivo fondamentale: nei moderni SSD 
ogni cella di memoria può essere resettata poche migliaia di volte: 
resettarla a ufo accorcia inutilmente la vita dell'SSD.
Si noti bene: anche questo consiglio sulla dimensione del file ha senso 
solo se discard (TRIM) di per sé non resetta ma semplicemente comunica.
 
[*] 
http://andyduffell.com/techblog/?p=852
 
 
Orbene, ora si quaglia.
Se io creo un file piccolissimo, con:
 
$ echo pippo > pippo && sync
 
e poi lo cancello
 
$ rm pippo && sync
 
ed eseguo il mio bel trim manuale
 
$ sudo fstrim /
 
immancabilmente i pochi byte di "pippo", e quindi la pagina, e quindi il 
blocco di 512kB cui essa appartiene vengono resettati. Un blocco di 512kB, 
tutto vuoto ad eccezione di quel cazzo di "pippo", viene tutto resettato. 
E il disco è quasi tutto vuoto, per di più.
Ma siamo pazzi!?!?!?
 
Ricordiamoci: discard (TRIM) non resetta. Discard (TRIM) comunica 
informazioni al firmware del disco, che poi resetta quando e se lo 
ritiene opportuno, in base anche ad altre informazioni che lui e solo lui 
ha. Almeno io ho sempre letto così, ovunque.
 
Invece fstrim pare proprio ordinare lui un reset immediato, al quale 
ordine il firmware ubbidisce: non voglio credere che il firmware sia 
idiota da resettare di sua iniziativa blocchi quasi vuoti, coi 3/4 del 
disco già liberi! Insomma pare che fstrim somigli più a un tool di reset 
(seppur parziale) dell'SSD, che non al TRIM informativo di cui io ho 
sempre letto e saputo.
 
Com'è 'sto fatto? Qualcuno è in grado di darmi dei lumi?
 
Ora l'ultima domanda: ma di 'sta roba gliene frega niente a nessuno? 
Nessuno con un SSD? Ho anche postato su ubuntuforums e su phoronix la 
questione del discard che non va: 150 visualizzatori e 0 risposte, manco 
per dirmi «Crepa!». A me sembrerebbero argomenti interessanti, se non 
preoccupanti.
-- 
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/
 

 preoccupanti.
 
Io ho un OCZ Onyx da 32gb per /
 
Secondo me non è che "non gliene frega niente a nessuno", è che andare a 
smanettare attorno a kernel e filesystem è sempre abbastanza invasivo 
e/o rischioso...
 
Io ad esempio avevo letto
http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support
 
http://en.opensuse.org/SDB:SSD_Idle_Time_Garbage_Collection_support
 
 
e avevo inteso, forse sbagliando, che se l'ssd ha un garbage collector 
abbastanza efficiente di suo, viene usato per dati prevalentemente 
statici, ed è in gran parte vuoto, non dovrebbe avere troppi problemi.
 
Inoltre, sempre lì avevo letto che non è detto che il trim sia sempre e 
comunque ottimale...
 
Quindi, non so se sia stato giusto o sbagliato, ho pensato di lasciare 
tutto com'è di default in attesa che la situazione si chiarisca.

 preoccupanti.
 
Io ho un SSD ma ho fatto terribilmente fatica, per limiti miei, a 
seguire quel che scrivevi.
 
Mi è parso di capire che la vita dell'SSD potrebbe risultare accorciata 
rispetto al possibile, il che non è tranquillizzante.
 
Di sicuro c'è che, purtroppo, non ho il know-how per andare attorno al 
firmware od al kernel...
 
Un saluto.


 
-- 
bye
!(!1|1)
 
 

 Ora l'ultima domanda: ma di 'sta roba gliene frega niente a nessuno?
 
a me sì ma non ci perdo il sonno ;-P
ho seguito alcuni consigli quando ho partizionato il disco: lasciare qlc 
giga non formattato, usare fs senza journal (sono protetto da un UPS), 
mettere /home, /var e /tmp su HD, noatime e discard e altro in fstab;
fatto questo mi sono messo il cuore in pace, quando si rompe o degrada 
troppo lo sostituisco;
 
r
 
ps
ho fatto il test e il discard sembra non funzionare, forse perché non 
c'è il journal? pazienza
 
-- 
 
Io pagare le puttane? mica son giudici.
[Silvio "Portafogli in mano" Berlusconi]
 
Un Minuto Per Favore:
Home Page, The Pentangle, I Salon di Baudelaire: 
http://www.umpf.net
 
 

 The TRIM command [...]
 
Grazie.
Quindi sembra che io fossi nel giusto riguardo alla valenza puramente 
informativa del TRIM.


 pazienza
 
Ok, ma almeno sappiamo che succede. In rete spesso si consiglia di usare 
discard senza journal. Se vien fuori che è un controsenso, abbiamo una 
novità (almeno per me).


 Ora l'ultima domanda: ma di 'sta roba gliene frega niente a nessuno?
 
Ovviamente ringrazio tutti coloro che hanno avuto la pazienza di 
leggermi, e di interessarsi al problema. Mi scuso se non tutti sono 
riusciti a seguirmi agilmente, la colpa è stata certamente mia.


 novità (almeno per me).
 
OK, prova fatta. Abilitando il journal, discard mi funziona.
 
Quindi è la mancanza del journal a inibire discard (invece fstrim 
funziona comunque).
 
La cosa IMHO brutta è che anche discard funziona alla moda di fstrim: 
tutto quello che viene discardato viene immediatamente resettato, anche 
se non ce ne sarebbe alcun bisogno. Qui sarebbe bello sapere se la cosa è 
dovuta alla particolare implementazione del discard con ext4, o al fatto 
che il firmware (versione 02) del Crucial M4 è scemo.


 informativa del TRIM.
 
quindi sarebbe ext4 a disabilitare discard quando non è abilitato il 
journaling?...
 
se non esistono due differenti comandi ATA per il trim immediato e per 
quello demandato all'algoritmo del firmware, i frequenti aggiornamenti 
del file di journaling potrebbero semplicemente causare, come effetto 
collaterale, un aumento della frequenza delle operazioni di trim...
 
penso che per dissipare ogni dubbio bisognerebbe chiedere ai 
responsabili della manutenzione del codice di ext4/fstrim o guardare 
direttamente nei sorgenti
 
-- 
bye
!(!1|1)
 

 che il firmware (versione 02) del Crucial M4 è scemo.
 
Penso che sia una "feature" di ext4, visto che anch'io ho riscontrato un reset 
quasi immediato del blocco che ho controllato. Non saprei dire pero` se sia un 
male, ovvero che il blocco venga resettato subito o dopo tot minuti e` 
(relativamente) indifferente
 
Enrico
 

 reset quasi immediato del blocco che ho controllato. 
 
C'è una terza possibilità, che mi è appena stata suggerita su phoronix:
 
- se non vedo gli zeri, trim/discard non funzionano;
- se li vedo, discard/trim funzionano, ma comunque non c'è modo di sapere 
se gli zeri vengono direttamente dalla memoria flash o se sono simulati 
dal firmware: ed è probabile che siano simulati dal firmware, che quindi 
non resetterebbe subito se non necessario.
 
A naso io direi sia così.


 riusciti a seguirmi agilmente, la colpa è stata certamente mia.
 
Grazie a te per il post molto utile, io per esempio ignoravo queste cose 
(non ho ancora toccato SSD) e sono cose molto utili da sapere.

 leggermi, e di interessarsi al problema.
 
C'e` comunque da fare un appunto: in tutta questa storia, nessuno ha 
controllato come si comporta btrfs (anche se c'e` da dire che ci vorra` ancora 
un po' prima che qualcuno lo utilizzi come file system di default)
 
Enrico

 default)
 
Infatti: btrfs è comunque molto più lento di ext4 nella stragrande 
maggioranza dei casi, ed essendo pure meno maturo... per ora volentieri 
lo lascio stare.
 
Piuttosto vorrei verificare personalmente quanto possa essere il vero 
overhead del giornale di ext4.
 
Per i test non utilizzerò l'SSD, ma due partizioni su disco meccanico: 
una per il fs, una per il giornale.
 
Per ora ho provato solo la prima cosa che mi è venuta in mente: ho 
testato la differenza fra:
 
$ while true ; do echo pippo >> file ; done
 
e
 
$ while true ; do echo pippo >> file && sync ; done
 
monitorando con:
 
$ dstat --bw -r -d -D sdh2,sdh3
 
(sdh2 e sdh2 sono rispettivamente giornale e fs). LOL! :)
 
Se qualcuno ha in mente:
 
a) operazioni significative da eseguire come test;
b) configurazioni da testare (pensavo a ioscheduler e a opzioni di mount 
di ext4 relative a tipo di giornale, barrier, commit...);
c) programmi di monitoring migliori
 
sappia che ogni suo suggerimento è il benvenuto.
