Dopo qualche ricerca piuttosto superficiale non ho trovato uno scheduler decente per le SSD sotto linux.
Per SSD intendo esplicitamente i dispositivi flash-based non MTD (quindi ATA, USB storage, SCSI, SD/MMC/CF/MS/XD o che altro) . Questa classe di dispositivi sono abbastanza difficili da gestire perchè nascondono il fatto di essere sotto sotto degli MTD e così facendo impediscono di conoscere gli internals e quindi fare le cose fatte bene.
Purtroppo non essendoci uno scheduler specifico le prestazioni non saranno ottimali. Una SSD non ha problemi di seeking e ordinare le richieste secondo la posizione su disco, o peggio ancora dare priorità ad un richiesta perché è vicina a quella precedente non può che aumentare la latenza. Il read-ahead poi peggiora ulteriormente le cose leggendo dati potenzialmente inutili senza trarne alcun vantaggio.
Vediamo come neutralizzare questi meccanismi sotto linux.
Un metodo molto semplice potrebbe essere usare lo scheduler noop, che esegue le richieste in ordine di arrivo.
Quindi, per il disco sda si procede come segue:
echo noop > /sys/block/sda/queue/scheduler
Inoltre bisogna ridurre il read-ahead, in quanto non è costoso ritornare su una determinata “posizione” per leggere i dati. In realtà c’è il costo di mettere in coda una nuova richiesta e aspettare che venga soddisfatta, ma questo è poco rilevante in confronto a fare una lettura per nulla. Il read ahead viene fatto comunque (anche per letture di i-node, file microscopici…) quindi è piuttosto pesante.
Quindi mettiamo un valore basso, a naso 
echo 8 > /sys/block/sda/queue/read_ahead_kb
La cosa migliore sarebbe mettere la dimensione di un blocco flash (che non conosciamo) e avere le richieste allineate al blocco. Ma non si può, pazienza…
Questa non è ancora una soluzione completamente ottimizzata, ma un ripiego. Infatti una caratteristica propria delle SSD (o meglio di quasi tutte le flash) è avere una velocità di scrittura molto più bassa di quella di lettura, in genere il rapporto è 50% o 25% o in casi sfortunati anche il 10%. Sarebbe quindi opportuno riordinare le richieste dando priorità alla lettura in maniera proporzionale al rapporto medio tra le due velocità, ovviamente avendo una qualche deadline dopo la quale scrivere comunque i dati.
In definitiva non riusciamo ad avere una soluzione completa, ma comunque abbiamo degli incrementi nelle prestazioni. In fondo questi dispositivi dovrebbero essere temporanei in attesa che i sistemi operativi supportino tutti nativamente i dispositivi MTD. Linux li supporta da un pezzo, ma sul mercato non troveremo mai MTD da 8 Gb, proprio perchè avrebbero poco mercato grazie ad altri sistemi operativi, senza fare nomi 
.
6 Gennaio – e quindi Buon LolCompleanno Kiwi -
ma tipo.. se mi leggo tutto tutto tutto il tuo blog poi posso chiederti una cosa sulla wireless + wpa_supplicant + debian??
ciao Kiwi e grazie per il tuo post.
volevo solo chiederti qualche informazione, dato che ho provato i tuoi suggerimenti sul mio aspier one con risultati che sono andati all’opposto rispetto a quanto mi aspettavo.
utilizzando 8 come valore per /sys/block/sda/queue/read_ahead_kb, mi si è dimezzata la velocità di scrittura che è passata da 38.55 Mb/s a 17.
come test ho usato un semplice:
hdparm -Tt /dev/sda
mi puoi piegare il motivo? sto cercando di decidere se usare deadline o noop comne scheduler ma non riesco a sbrogliare molto la matassa…
Ciao Max,
quella che hai determinato è la velocità di lettura, ed è normale che scenda.
17 MB al secondo sono comunque tanti rispetto a quella di scrittura (che sarà sotto il MB/sec).
Quello che fa quel settaggio è evitare di perdere molto tempo a fare letture potenzialmente inutili (read ahead, letture “speculative” per intenderci), sapendo che il problema grosso delle SSD è la scrittura.
In questo modo durante un utilizzo tipico (letture e scritture miste) si evita che si accodino tante richieste di lettura durante una scrittura.
Comq ho scritto nel post, questa non è una soluzione proprio ideale, ma credo sia il meglio che si possa fare ora.
In realtà si potrebbe capire quale è la dimensione dei blocchi delle SSD e allinearci il filesystem (e magari se lo supporta mettere i blocchi della stessa dimensione).
Ora il mio “acerone” non lo sto usando molto, ma quando lo riprenderò in mano farò delle prove con brtfs che sembra supportare blocksize belli grandi (64k, devo verificare).
Vale la pena fare delle prove perchè gli stessi risultati si possono applicare alle chiavette USB. Quando ho novità farò un nuovo post
ciao Kiwi
volevo il tuo parere su una idea balzana che mi è venuta in mente leggendo questo post sul forum di OCZ:
http://www.ocztechnologyforum.com/forum/showpost.php?s=313aff9f1fe2ef1c86af597440d6f320&p=373226&postcount=98
dato che li si dice chi si può evitare il problema dei blocchi saltando la tabella delle partizioni e scrivendo il filesystem direttamente sul device, ho pensato che per chi ha un netbook che vede al boot il card reader come disco usb (non chi come noi ha un aspire one
) potrebbe mettere la partizione di boot sulla scheda shdc e poi formattare direttamente il device /dev/sda e montarlo su /
in quanto al filesystema, stavo leggendo questo articolo su linux-mag:
http://www.linux-mag.com/id/7345/2/
che magnifica le doti di nilfs.
che ne pensi?
Ciao Max,
molto interessante l’articolo su OCZ.
Se capiamo quanto è il blocksize si potrebbe provare l’approccio 1, cioè quello di allineare la partizione, così possiamo anche fare il boot.
Anzi, adesso prendo il portatile e cerco il datasheet!
Il mio SSD è il p-ssd1800 (per vedere il tuo hdparm -i /dev/sda)
Sono fortunato è il Samsung, quello “veloce”. Non voglio sapere quello “lento” Intel che prestazioni ha…
Intanto ho trovato questo:
http://www.ssdflashdrivereviews.com/flash-drive-review/Acer-Aspire-One-P-SSD1800-Ver2-8GB-Windows-7.php
Guarda in fondo, il grafico sulle performance di scrittura.
Questo benchmark suggerisce una dimensione di 64KB (vedi che la write speed non migliora usando blocksize più grandi? è un dato statistico molto significativo)
Riguardo NILFS devo ancora farmi un idea precisa.
Ho letto rapidamente il paper del test, scritto della Samsung. Loro hanno comodamente allineato il filesystem alla blocksize flash
NILFS è strutturato a log quindi se non altro evita di scrivere troppo spesso negli stessi posti. In teoria poi le scritture sono sequenziali, e se vengono flushate non troppo spesso c’è anche il rischio che le prestazioni aumentino (richieste molto grandi di settori contigui -> meno blocchi flash riscritti per niente)
Ad esempio due scritture grandi 4KB (di due file diversi) scriverebbero due volte blocchi flash da 64KB su un ext3 (senza contare i metadati, probabilmente arriveremmo a 3 blocchi flash). Su NILFS (e qualsiasi filesystem a log), se le richieste vengono unite prima di essere scritte dovremmo avere una sola richiesta in append al log probabilmente grande <64KB, scrivendo un solo blocco flash.
Guardando il paper originale http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf si vede che le richieste sono sempre di 128KB!
Questo vuol dire che ogni volta che il filesystem scrive, (se ha abbastanza dati ovviamente), scrive due blocchi flash alla volta.
Notare che nel paper manca il case study per NILFS.. Peccato! Avrei voluto confrontare (magari confermare) la mia ipotesi.
Comunque la prima impressione è buona.
I miei dubbi sono: è abbastanza stabile come filesystem? (non ha neanche un fsck). Cosa succede se faccio una richiesta piccola (un file di pochi byte, ad esempio quelli creati al boot in /var) e lascio che venga scritta, cioè la lascio isolata nel tempo? Non è che si disallineano le richieste successive rispetto ai blocchi?
Il benchmark è qualcosa di artificiale che va a riempire le code di scrittura per alcuni secondi o minuti. Nell'utilizzo normale questo succede "solo" quando si copia un file grosso o si estrae un archivio. Non vorrei che in usi più tipici le cose peggiorino. Mai quanto usando ext3 o anche ext2 comunque
É comunque sorprendente quanto sia performante nonostante non sia un filesystem volutamente nato per le SSD. Nel TODO c'è "ottimizzazioni per SSD". Devo dire che gli manca veramente poco.
Grazie del link! Io avevo sempre cercato filesystem che supportassero blocchi (del fs) grandi, ma in realtà quello che serve è riuscire a fare richieste grandi ed allineate al blocco flash. Non è necessariamente la stessa cosa
Non avrei paura del wear, sono sicuro che è meglio su un filesystem a log che su qualsiasi altro non a log.
Ora che ho anche un altro portatile posso pensare di pasticciare con reinstallazioni e test.