Newsgroup: it.comp.os.linux.iniziare
Titolo: Ext4 discard (TRIM) che non funziona

Sono su Ubuntu Oneiric x86_64, kernel 3.0.0-12-generic.
 
Ho un SSD capace di TRIM (Crucial M4):
lem@biggy:~$ sudo hdparm -I /dev/sda |grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read data after TRIM
 
Su questo SSD sta la / (/dev/sda2), che è un ext4 senza journal montato 
coll'opzione discard.
 
Bene - anzi male. Il TRIM automatico di ext4, dato dall'opzione discard, 
_non_ funziona.
 
Verifico così. Mi posiziono in una directory che sta su /dev/sda2 - nella 
fattispecie la mia home - poi:
 
$ dd if=/dev/urandom of=testfile bs=1M count=3 && sync
 
$ sudo hdparm --fibmap testfile
 
In base all'output scelgo uno dei settori logici occupati dal file 
(aggiungo almeno 1024 al primo settore del file), e do:
 
$ sudo hdparm --read-sector [settore] /dev/sda
 
che mi restituisce appunto i dati casuali scritti da urandom.
 
Cancello il file:
 
$ rm testfile && sync
 
Aspetto alcuni minuti, per lasciare il tempo al firmware dell'SSD di fare 
le sue cose (ho aspettato anche ore), e poi ridò:
 
$ sudo hdparm --read-sector [settore] /dev/sda
 
Se il TRIM avesse funzionato, dovrei leggere tutti zeri, invece leggo 
ancora i dati casuali di prima.
 
Se però eseguo il TRIM manualmente:
 
$ sudo fstrim -v /
 
eseguendo poi il solito:
 
$ sudo hdparm --read-sector [settore] /dev/sda
 
leggo immediatamente tutti zeri.
 
Quindi il TRIM manuale funziona, ma quello automatico di ext4, dato 
dall'opzione "discard", no.
 
La cosa mi pare piuttosto grave.
Mi piacerebbe sapere, da qualcuno con un SSD, che risultati gli dà un 
test analogo. Grazie mille in anticipo.
-- 
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/
 

 _non_ funziona.
 
E, dimenticavo, anche la modalità AHCI è attiva. Quindi discard dovrebbe 
proprio funzionare, AFAIK.


 test analogo. Grazie mille in anticipo.
 
per comprarlo aspetto che gli impavidi risolvano prima i problemi :-p
 
-- 
bye
!(!1|1)
 

 dall'opzione "discard", no.
 
Hai controllato in cat /proc/mounts se c'è il discard?
 
Prova, invece di /dev/urandom, a scrivere un file di testo.
Anche ls -lR /proc >nomefile andrebbe bene.
 
 
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
 
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 
 
 

 Hai controllato in cat /proc/mounts se c'è il discard?
 
Sicuro.
 
In /etc/fstab ho:
[...]
UUID=3c6d0664-9bc1-4f70-973d-b8c428416ae9 / ext4 noatime,discard,errors=remount-ro 0 1
[...]
 
Con mount ottengo:
lem@biggy:~$ mount
/dev/sda2 on / type ext4 (rw,noatime,discard,errors=remount-ro)
[...]
 
Con mtab ho:
lem@biggy:~$ cat /etc/mtab
/dev/sda2 / ext4 rw,noatime,discard,errors=remount-ro 0 0
[...]
 
Leggendo /proc/mounts:
[...]
/dev/disk/by-uuid/3c6d0664-9bc1-4f70-973d-b8c428416ae9 / ext4 rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,stripe=128,discard 0 0
[...]
 
Quindi discard compare sempre.
 
Va beh, per l'uso che faccio di quella partizione posso mettere
fstrim in crontab due volte la settimana, e levare l'opzione
discard.
Però vorrei davvero capire che succede.


 Però vorrei davvero capire che succede.
 
Fai la prova con un file di testo per assicurarci che il 'random'
che vedi 'dopo' sia davvero lo stesso...
Con il TRIM AFAIK non c'è nemmeno da aspettare, il cambio di
celle dovrebbe essere immediato.


 che vedi 'dopo' sia davvero lo stesso...
 
Dopo un TRIM riuscito si vedono tutti zeri, ben riconoscibili. :)
Comunque ho fatto la prova anche col file di testo, purtroppo stesso 
risultato. :(


 _non_ funziona.
 
Cercando qualche info sull'argomento ho trovato questa patch che spero possa risolverti il 
problema:
http://www.spinics.net/lists/linux-ext4/msg18874.html
 
 
 

 
http://www.spinics.net/lists/linux-ext4/msg18874.html
 
 
Ti ringrazio davvero molto per avermi aiutato.
Quello che hai trovato è molto interessante.
 
Francamente spero però si tratti di altro:
a) la patch è addirittura di un anno e mezzo fa: spero bene che nel 
frattempo il problema sia emerso ufficialmente, sia stato affrontato e 
risolto;
b) non sono in grado di capirne bene la portata;
c) per quanto autorevole ne sia l'autore, non userei comunque qualcosa di 
non ufficiale su di un componente assolutamente critico come il 
filesystem.
 
Presto controllerò se il problema si risolve aggiungendo un journal.
 
Grazie ancora! :)
 
*Problema*: è accettabile mettere un journal esterno su un disco ram?
Visto che la mia idea era quella di usare ext4 *senza* journal, non posso 
comunque perder nulla, in termini di sicurezza, mettendolo in ram. O no?
Così al boot ext4 partirebbe senza journal, uno script d'avvio creerebbe 
il journal in un disco ram e poi l'aggiungerebbe a /.
 
Insomma creerei uno script che al boot facesse:
 
mkfs.ext4 -b 4096 -O journal_dev /dev/ram0
tune2fs -J device=/dev/ram0 -O has_journal /dev/sda2
mount -o journal_data_writeback,barrier=0,remount /
 
e allo shutdown:
 
tune2fs -O ^has_journal /dev/sda2
 
*Timore*: e se lo shutdown non avvenisse correttamente? Che cosa 
capiterebbe quando la root, impostata per avere un journal esterno, non 
lo trovasse? Verrebbe semplicemente montata in ro (come da sua opzione 
errors=remount-ro) con quel che ne consegue? Direbbe brutte parole? 
Esploderebbe? Faccio prima un po' di prove con Virtualbox? ;)


 risolto;
 
Avevo notato anch'io la data ma ho postato ugualmente perche` leggendo qua e la` mi ero fatto 
l'idea che il problema non fosse ancora stato risolto; e` pero` solo una mia impressione e potrebbe 
tranquillamente essere errata.
 
 

 Esploderebbe? Faccio prima un po' di prove con Virtualbox?
 
Una volta che il fs è predisposto per avere un journal, se non lo trova 
NON può essere montato - a meno che non si usi l'opzione di montaggio 
"noload", che fa ignorare il giornale. Siccome io lavoro sulla /, per 
poter bootare debbo usare il kernel parameter "rootflags=noload". 
 
L'opzione "noload" in /etc/fstab è irrilevante per /. Ciò perché il fs, 
una volta montato con noload, non può essere rimontato *al* *volo* (mount 
-o remount...) abilitando il giornale. Noload è, e noload resta. Certo, 
se smontassi completamente il fs, e poi lo rimontassi... Ma non posso 
certo smontare la / !
 
Quindi tutta la mia ipotesi di mettere in ram un giornale esterno per / è 
fuffa.


 .... :-)
 
Ma va'? Grazie a me?
Mi farebbe davvero piacere essere stato così utile... ma mi sa tanto che 
mi confondi con qualcuno ben più ferrato. :)


 Visto che la mia idea era quella di usare ext4 *senza* journal
 
Non vedo il perche`, visto che le differenze sono abbastanza minime. A tal 
proposito, guarda anche questi: 
http://tytso.livejournal.com/61830.html
 
https://wiki.archlinux.org/index.php/Solid_State_Drives#Disabling_Journaling_on_the_Filesystem.3F
 
 
Enrico

 test analogo.
 
Fatto su Fedora 15 a 64bit con kernel 2.6.40.6-0.f15 ed una SSD Corsair da 
64Gb e funziona, ovvero il TRIM viene eseguito quasi istantaneamente
 
Enrico
P.S. ho il journal attivato

 Enrico P.S. ho il journal attivato
 
Ti ringrazio tantissimo. :)


 P.S. ho il journal attivato
 
Per abilitarlo io devo usare una live. Stasera cerco proprio di trovare 
il tempo. Poi saprò dire.


 il tempo. Poi saprò dire.
 
OK, prova fatta. Abilitando il journal, discard funziona anche a me.
 
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 n'è alcun bisogno. Qui sarebbe bello sapere se la cosa è dovuta 
alla particolare impelementazione del discard con ext4, o al fatto che il 
firmware (versione 02) del Crucial M4 è scemo.
