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 .

Vediamo intanto le caratteristiche:

• Intel(R) Atom(TM) CPU N270 @ 1.60GHz
• 512 Mb DDR2 PC2-4200 + 1 slot libero (poco accessibile)
• 8 GB di SSD su CF interna
• Audio integrato Intel ICH7
• Ethernet 10/100/1000 (ufficialmente è 100 Mb ma vedo che fa il link in Gb) correzione: fa l’advertise di Gb ma poi non va
• Wireless Atheros AR2425 802.11g
• 3 Usb 2.0
• Schermo 1024×600 9″ con backlight a LED
• 2 Slot SD (uno per aumentare lo storage, uno come lettore 10000 in 1 )
• Linpus Linux (ehhh?)

Beh non è il caso di fare un’altra review per questo aggeggino, vediamo piuttosto come si comporta con una distro normale . Linpus linux è ideale per un neofita (si dice così niubbo vero?), nel senso che veramente è di una facilità disarmante e un non informatico può veramente credere di poterci fare TUTTO,  a parte giocarci.

Ma il mio scopo era usarlo da power user quindi ho brasato via tutto e messo su una bella Fedora 9.

Bootata da usb live, si è fermata tipo 2 minuti a caricare senza successo il modulo dell’audio, rimanendo in hang.  Inoltre niente wireless e ethernet durante l’installazione. Il primo non ha i driver, il secondo panica (solo il modulo)

Tutto questo non mi ha impedito di continuare l’installazione. Ovviamente una volta installata i problemi permanevano, ma era inutile cercare di sistemarli a mano mi sono detto,  basterà aggiornarla.

Peccato fossi senza connettività.Mi è stata utilissima a tale scopo una chiavetta wireless usb. Rebootando con il kernel nuovo l’ethernet ha cominciato a funzionare, ma il wireless sembra coperto da un radio kill switch che non riesco a spegnere. Dovevo vedere cosa faceva linpus… Ma pazienza!

Come prestazioni, come potete immaginare il boot è molto veloce (niente seeking ) mentre le operazioni di scrittura da SSD sono veramente lente. Penso sia una SSD di qualità abbastanza scadente. Poco male ho già acquistato una CF da 8 Gb, vi farò sapere quando mi arriva.

Inoltre con così poca RAM, lo swap si usa in maniera abbastanza pesante, ed essendo su una SSD lenta, potete immaginare i risultati.

In conclusione: Se vuoi cambiare distro c’è assolutamente da aumentare la RAM. Eventualmente cambiare l’SSD con una migliore O usare lo storage esterno almeno per lo swap e per la home.

PS: se usi Fedora e hai anche tu questo portatile aiutami a correggere la pagina della wiki!